From Ed.Lewis@neustar.biz Mon Apr 5 10:50:03 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157FB3A67EF for ; Mon, 5 Apr 2010 10:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_60=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2cOA+kJp7KP for ; Mon, 5 Apr 2010 10:49:58 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id C63A83A67C2 for ; Mon, 5 Apr 2010 10:49:52 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o35Hnheg073148; Mon, 5 Apr 2010 13:49:43 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Mon, 05 Apr 2010 13:49:49 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 05 Apr 2010 13:49:49 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 5 Apr 2010 13:49:41 -0400 To: Edward Lewis From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: ed.lewis@neustar.biz, ire@ietf.org Subject: Re: [ire] Draft of IETF 77 BoF Notes X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 17:50:03 -0000 Please submit comments on these (if any) this week so they can be submitted for the proceedings... >Draft of notes > >Please post comments to the list or to the chairs >================================================================== > >This is a summary of the issues raised during the BoF, sorted into >categories. There is an audio recording of the session is >available, if further detail and personal attribution is needed. > >To access the audio recording, go to: > > http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf77/ > >and find the file named: > > ietf77-ch8-wed-am.mp3 > >Our session is from from 1h37m40s to 2h39m12s on the "tape". > >The full URL for the audio file is here: >http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf77/ietf77-ch8-wed-am.mp3 > >Escrow Problem Domain > > Basic scope - the relationship of objects (like domain names, IP address > ranges) to entities (people, organizations). Ancillary information like > contact roles, addresses. Operational information related to registrants > like registered servers and meta-data. Slippery slope - operational > parameters of the registration entity. > > Is not the same thing as system backups. Different collection practice, > different retrieval methods. > > History of data - can be included within an escrow drop but escrow drops > don't constitute a history. ("Title searches.") ("Escrow drop" is one > instance of the escrow, usually visualized as a file or a set of files.) > > Policies - usually available via other means, set by other means (by the > regulator for instance), therefore not envisioned in the escrow. > > What is in a registry's registration database is in scope. > > Q: Why so many "exclusions?" > A: Perception of registry scope is wider than the reality. Registration > organizations offer many side services, which makes the problem seem > bigger > > DNSSEC private keys - not in escrow, this is part of operations parameters > > Public keys held for DNSSEC (or other purposes) - in scope > >Escrow Actors > > Usually the registration body, the regulator (requires it), and the > third party that holds the information. > > Role of law enforcement - considered external to problem domain, which is > deriving the format of the data, not a discussion of policies over it > >Escrow Policies > > One policy that borders in-scope and out-of-scope is the protection > of the Escrow "drop" itself. It might be "up to the regulator" to > specify this, nevertheless, a discussion of this issue should be present > in any IETF document produced on the topic. > > Out of scope for the work, each regulator can specify these differently for > their registration space > Security considerations, including authorization to read (access)/write. > > The transit of the data is undefined, that is a matter usually determined > by the third party holding the escrow. > >Escrow Purpose > > WG scope is to define a format for what is essential to reconstitute a > registration body. (Time budget is undefined.) > > Not for transfer of registry operations - this has been done before with > out escrow (SRI-NIC to Network Solutions, .ORG, others). > >Why IETF? > > This work comes from a need identified within ICANN but is a problem more > general than the environment within ICANN. ICANN has generated a few > attempts to solve this but nothing sufficiently general. > > IETF provides a global view (wrt registration), is inclusive of >domain names, > of any kind (gTLD, ccTLD, IDN), and network identifiers (RIRs), and has > technical expertise for generating the formatting needed. However, it is > recognized that not all of the involved entities will actively participate > without much encouragement and outreach. > >BoF Concerns and Polls > > No work should be open ended, balanced against bringing in a >solution seeking > a "rubber stamp" of approval. > > Charter presented doesn't match the draft. > > Still a large group to consult on this issue, to determine whether it is > "global" or something specific to ICANN. One next step is to establish > that there is an appropriate spread of interest that would lead this to > be a fit for the IETF. (E.g., do any of the RIRs care about escrow?) > > Chairs asked for a show of hands and a super-majority of the ones > present wanted to have this work inside the IETF. There were a > "non-negligible to to noticeable to significant" number of "no's" > and "abstains" > > Chairs also asked about if people have clarity about the possible > scope of the working group; very few people believed so. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 New pithy statement under construction... From Ed.Lewis@neustar.biz Tue Apr 13 06:03:13 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7B23A68A3 for ; Tue, 13 Apr 2010 06:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.819 X-Spam-Level: X-Spam-Status: No, score=0.819 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Zz3ZZWuUdzD for ; Tue, 13 Apr 2010 06:03:13 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 000503A68E7 for ; Tue, 13 Apr 2010 06:03:12 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3DD30Gn044260; Tue, 13 Apr 2010 09:03:01 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [192.168.1.104] by Work-Laptop-2.local (PGP Universal service); Tue, 13 Apr 2010 09:03:06 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Tue, 13 Apr 2010 09:03:06 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 13 Apr 2010 09:02:58 -0400 To: ire@ietf.org From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: [ire] Minutes uploaded X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 13:03:14 -0000 FYI, the minutes have been uploaded. Just 103 more days until the next IETF! Upcoming "important dates" for that meeting: 2010-04-26 (Week of): IETF Online Registration opens. 2010-04-26 (Monday): Working Group and BOF scheduling begins. 2010-06-01 (Tuesday): Cutoff date for BOF proposal requests to ADs 2010-06-14 (Monday): Cutoff date for requests to schedule WG meetings 2010-06-14 (Monday): Cutoff date for Area Directors to approve BOFs -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From Ed.Lewis@neustar.biz Mon Apr 19 09:42:13 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C343A6CBA for ; Mon, 19 Apr 2010 09:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.872 X-Spam-Level: X-Spam-Status: No, score=0.872 tagged_above=-999 required=5 tests=[AWL=0.871, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pilUEi2vE3R6 for ; Mon, 19 Apr 2010 09:42:12 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 0B8F328C3B0 for ; Mon, 19 Apr 2010 09:23:00 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3JGMj6r001288; Mon, 19 Apr 2010 12:22:45 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Mon, 19 Apr 2010 12:22:50 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 19 Apr 2010 12:22:50 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 19 Apr 2010 12:22:43 -0400 To: ire@ietf.org From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 16:42:13 -0000 At 9:02 -0400 4/13/10, Edward Lewis wrote: (I live for the snooze bar!) Just 7 more days until the *scheduling* for IETF 78 begins. Seven days! Check it - from the key dates page: 2010-04-26 (Monday): Working Group and BOF scheduling begins. When we left Anaheim, we had some work ahead of us to establish this work more firmly as fodder for a WG. Having work to do is fine, executing and documenting it is even more important. One of the principle, principal, err, most important things we need to get moving on is a framework for the escrow. If I recall correctly, a bit more detail in this area would let "fence sitters" (those not sure if this might be a WG or not) get a better idea of the work ahead of us. It's been a months since we left Anaheim, I think it's time to get some progress. Also, in about 10 days we will be into a RIPE meeting, having been through a DNS-OARC and CENTR-Tech meeting where interest parties will be gathering. Even more reason to show some progress. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From paul.hoffman@vpnc.org Mon Apr 19 14:37:02 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7D963A68DB for ; Mon, 19 Apr 2010 14:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.105 X-Spam-Level: X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[AWL=-2.659, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0aqN2SISbEy for ; Mon, 19 Apr 2010 14:37:02 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 008653A6781 for ; Mon, 19 Apr 2010 14:37:01 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o3JLapen003663 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Apr 2010 14:36:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 19 Apr 2010 14:36:50 -0700 To: Edward Lewis , ire@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: ed.lewis@neustar.biz Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Apr 2010 21:37:02 -0000 At 12:22 PM -0400 4/19/10, Edward Lewis wrote: >At 9:02 -0400 4/13/10, Edward Lewis wrote: > >(I live for the snooze bar!) > >Just 7 more days until the *scheduling* for IETF 78 begins. Seven days! > >Check it - from the key dates page: > 2010-04-26 (Monday): Working Group and BOF scheduling begins. > >When we left Anaheim, we had some work ahead of us to establish this work more firmly as fodder for a WG. Having work to do is fine, executing and documenting it is even more important. > >One of the principle, principal, err, most important things we need to get moving on is a framework for the escrow. If I recall correctly, a bit more detail in this area would let "fence sitters" (those not sure if this might be a WG or not) get a better idea of the work ahead of us. > >It's been a months since we left Anaheim, I think it's time to get some progress. Also, in about 10 days we will be into a RIPE meeting, having been through a DNS-OARC and CENTR-Tech meeting where interest parties will be gathering. Even more reason to show some progress. Is there much interest from the parties that are currently required, or are likely to be required in the near future, that this be standardized? I heard a lot of pushback from those folks in Anaheim. My interest in this work is as a neutral party who would want to become a trusted escrow agent for the registries. That means that I have no downside risk from the IETF creating the format, and some good upside possibility (assuming we do it right). That only gives *me* incentive for this work to happen; it is not at all sufficient for the IETF to take it on. Without the more-directly affected stakeholders wanting to help in an open environment, forming a WG is not a good idea. --Paul Hoffman, Director --VPN Consortium From francisco.arias@icann.org Mon Apr 19 23:47:02 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58CAF3A68E3 for ; Mon, 19 Apr 2010 23:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrZVB2ALC2nm for ; Mon, 19 Apr 2010 23:47:01 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id 5781728C0E4 for ; Mon, 19 Apr 2010 23:46:59 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 19 Apr 2010 23:46:50 -0700 From: Francisco Arias To: Edward Lewis , "ire@ietf.org" Date: Mon, 19 Apr 2010 23:46:48 -0700 Thread-Topic: [ire] Prodding by one of the chairs Thread-Index: Acrf30zkX1ll0waWRdqTS3Bf8zD0OQAdfLfv Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 06:47:02 -0000 I'm working on having something out in a couple of weeks. Sorry for the delay. __=20 Francisco On 4/19/10 9:22 AM, "Edward Lewis" wrote: > One of the principle, principal, err, most important things we need > to get moving on is a framework for the escrow. If I recall > correctly, a bit more detail in this area would let "fence sitters" > (those not sure if this might be a WG or not) get a better idea of > the work ahead of us. From francisco.arias@icann.org Mon Apr 19 23:50:10 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 327413A6A73 for ; Mon, 19 Apr 2010 23:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p98oM8Co6tcz for ; Mon, 19 Apr 2010 23:50:09 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 5939B3A68F2 for ; Mon, 19 Apr 2010 23:50:09 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 19 Apr 2010 23:50:00 -0700 From: Francisco Arias To: Paul Hoffman , Edward Lewis , "ire@ietf.org" Date: Mon, 19 Apr 2010 23:49:59 -0700 Thread-Topic: [ire] Prodding by one of the chairs Thread-Index: AcrgCH0E89FRzwisTTmlAJB5D//g1gATTSXN Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 06:50:10 -0000 Hi, Paul. I got a different feeling from the meeting. There was a good number of registries gTLDs and ccTLDs and at least one RIR interested on this. __=20 Francisco On 4/19/10 2:36 PM, "Paul Hoffman" wrote: > At 12:22 PM -0400 4/19/10, Edward Lewis wrote: >> At 9:02 -0400 4/13/10, Edward Lewis wrote: >>=20 >> (I live for the snooze bar!) >>=20 >> Just 7 more days until the *scheduling* for IETF 78 begins. Seven days! >>=20 >> Check it - from the key dates page: >> 2010-04-26 (Monday): Working Group and BOF scheduling begins. >>=20 >> When we left Anaheim, we had some work ahead of us to establish this wor= k >> more firmly as fodder for a WG. Having work to do is fine, executing an= d >> documenting it is even more important. >>=20 >> One of the principle, principal, err, most important things we need to g= et >> moving on is a framework for the escrow. If I recall correctly, a bit m= ore >> detail in this area would let "fence sitters" (those not sure if this mi= ght >> be a WG or not) get a better idea of the work ahead of us. >>=20 >> It's been a months since we left Anaheim, I think it's time to get some >> progress. Also, in about 10 days we will be into a RIPE meeting, having= been >> through a DNS-OARC and CENTR-Tech meeting where interest parties will be >> gathering. Even more reason to show some progress. >=20 > Is there much interest from the parties that are currently required, or a= re > likely to be required in the near future, that this be standardized? I he= ard a > lot of pushback from those folks in Anaheim. >=20 > My interest in this work is as a neutral party who would want to become a > trusted escrow agent for the registries. That means that I have no downsi= de > risk from the IETF creating the format, and some good upside possibility > (assuming we do it right). That only gives *me* incentive for this work t= o > happen; it is not at all sufficient for the IETF to take it on. Without t= he > more-directly affected stakeholders wanting to help in an open environmen= t, > forming a WG is not a good idea. >=20 > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire >=20 From paul.hoffman@vpnc.org Tue Apr 20 07:30:52 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A2873A6A66 for ; Tue, 20 Apr 2010 07:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.007 X-Spam-Level: X-Spam-Status: No, score=-2.007 tagged_above=-999 required=5 tests=[AWL=-2.561, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jf3LhyT9JOJY for ; Tue, 20 Apr 2010 07:30:51 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 130E53A6AEF for ; Tue, 20 Apr 2010 07:25:52 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o3KEPJkk046958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Apr 2010 07:25:22 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 20 Apr 2010 07:25:18 -0700 To: Francisco Arias , Edward Lewis , "ire@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 14:30:52 -0000 At 11:49 PM -0700 4/19/10, Francisco Arias wrote: >I got a different feeling from the meeting. There was a good number of >registries gTLDs and ccTLDs and at least one RIR interested on this. I'm quite happy to be shown to be wrong about my impressions; that would help us for a WG to get real work done. Let them speak up here. --Paul Hoffman, Director --VPN Consortium From shollenbeck@verisign.com Tue Apr 20 09:16:28 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AD473A69DF for ; Tue, 20 Apr 2010 09:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.74 X-Spam-Level: X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXB5IC2ITVVW for ; Tue, 20 Apr 2010 09:16:27 -0700 (PDT) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id D9A213A6B83 for ; Tue, 20 Apr 2010 09:16:15 -0700 (PDT) Received: from dul1wnexcn01.vcorp.ad.vrsn.com (dul1wnexcn01.vcorp.ad.vrsn.com [10.170.12.138]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o3KFsQLs000448; Tue, 20 Apr 2010 11:54:26 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn01.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Apr 2010 12:16:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Apr 2010 12:16:03 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF070331E333@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ire] Prodding by one of the chairs Thread-Index: AcrglhJ7xYmxI8S2SJ2SoIz/uJ2QOgADoCPQ References: From: "Hollenbeck, Scott" To: "Paul Hoffman" , X-OriginalArrivalTime: 20 Apr 2010 16:16:05.0639 (UTC) FILETIME=[C74C1170:01CAE0A4] Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 16:16:28 -0000 > -----Original Message----- > From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On=20 > Behalf Of Paul Hoffman > Sent: Tuesday, April 20, 2010 10:25 AM > To: Francisco Arias; Edward Lewis; ire@ietf.org > Subject: Re: [ire] Prodding by one of the chairs >=20 > At 11:49 PM -0700 4/19/10, Francisco Arias wrote: > >I got a different feeling from the meeting. There was a good=20 > number of=20 > >registries gTLDs and ccTLDs and at least one RIR interested on this. >=20 > I'm quite happy to be shown to be wrong about my impressions;=20 > that would help us for a WG to get real work done. Let them=20 > speak up here. I'm not yet convinced that there's work here for the IETF. Scott From francisco.arias@icann.org Tue Apr 20 10:59:42 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB2928C192 for ; Tue, 20 Apr 2010 10:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dqt9h2ofXYUz for ; Tue, 20 Apr 2010 10:59:42 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id 2BFEF28C18C for ; Tue, 20 Apr 2010 10:59:42 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Tue, 20 Apr 2010 10:59:33 -0700 From: Francisco Arias To: "Hollenbeck, Scott" , Paul Hoffman , "ire@ietf.org" Date: Tue, 20 Apr 2010 10:59:32 -0700 Thread-Topic: [ire] Prodding by one of the chairs Thread-Index: AcrglhJ7xYmxI8S2SJ2SoIz/uJ2QOgADoCPQAAOp42U= Message-ID: In-Reply-To: <046F43A8D79C794FA4733814869CDF070331E333@dul1wnexmb01.vcorp.ad.vrsn.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Apr 2010 17:59:42 -0000 Hello, Scott. Why not? __=20 Francisco On 4/20/10 9:16 AM, "Hollenbeck, Scott" wrote: >> -----Original Message----- >> From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On >> Behalf Of Paul Hoffman >> Sent: Tuesday, April 20, 2010 10:25 AM >> To: Francisco Arias; Edward Lewis; ire@ietf.org >> Subject: Re: [ire] Prodding by one of the chairs >>=20 >> At 11:49 PM -0700 4/19/10, Francisco Arias wrote: >>> I got a different feeling from the meeting. There was a good >> number of >>> registries gTLDs and ccTLDs and at least one RIR interested on this. >>=20 >> I'm quite happy to be shown to be wrong about my impressions; >> that would help us for a WG to get real work done. Let them >> speak up here. >=20 > I'm not yet convinced that there's work here for the IETF. >=20 > Scott > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire >=20 From shollenbeck@verisign.com Wed Apr 21 04:12:37 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0F53A67EA for ; Wed, 21 Apr 2010 04:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.925 X-Spam-Level: X-Spam-Status: No, score=-4.925 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mm6Mf2+tevkl for ; Wed, 21 Apr 2010 04:12:36 -0700 (PDT) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id F04043A68DF for ; Wed, 21 Apr 2010 04:12:21 -0700 (PDT) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o3LAo9xs006067; Wed, 21 Apr 2010 06:50:09 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Apr 2010 07:11:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2010 07:11:49 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF070331E397@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ire] Prodding by one of the chairs Thread-Index: AcrglhJ7xYmxI8S2SJ2SoIz/uJ2QOgADoCPQAAOp42UAI6R2YA== References: <046F43A8D79C794FA4733814869CDF070331E333@dul1wnexmb01.vcorp.ad.vrsn.com> From: "Hollenbeck, Scott" To: "Francisco Arias" , X-OriginalArrivalTime: 21 Apr 2010 11:11:51.0095 (UTC) FILETIME=[71277470:01CAE143] Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 11:12:37 -0000 Primarily because there are working escrow implementations, such as the one developed to meet the requirements of the .COM agreement between VeriSign and ICANN*, already in place. I'm not convinced that there's enough benefit in a new escrow data format to outweigh the cost to define, implement, and deploy it. * http://www.icann.org/en/tlds/agreements/verisign/appendix-02-23jun09-en. htm Scott > -----Original Message----- > From: Francisco Arias [mailto:francisco.arias@icann.org]=20 > Sent: Tuesday, April 20, 2010 2:00 PM > To: Hollenbeck, Scott; Paul Hoffman; ire@ietf.org > Subject: Re: [ire] Prodding by one of the chairs >=20 > Hello, Scott. >=20 > Why not? >=20 > __ > Francisco >=20 >=20 >=20 > On 4/20/10 9:16 AM, "Hollenbeck, Scott"=20 > wrote: >=20 > >> -----Original Message----- > >> From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On > >> Behalf Of Paul Hoffman > >> Sent: Tuesday, April 20, 2010 10:25 AM > >> To: Francisco Arias; Edward Lewis; ire@ietf.org > >> Subject: Re: [ire] Prodding by one of the chairs > >>=20 > >> At 11:49 PM -0700 4/19/10, Francisco Arias wrote: > >>> I got a different feeling from the meeting. There was a good > >> number of > >>> registries gTLDs and ccTLDs and at least one RIR=20 > interested on this. > >>=20 > >> I'm quite happy to be shown to be wrong about my impressions; > >> that would help us for a WG to get real work done. Let them > >> speak up here. > >=20 > > I'm not yet convinced that there's work here for the IETF. > >=20 > > Scott > > _______________________________________________ > > ire mailing list > > ire@ietf.org > > https://www.ietf.org/mailman/listinfo/ire > >=20 >=20 >=20 From drc@virtualized.org Wed Apr 21 09:46:50 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 793343A6CB8 for ; Wed, 21 Apr 2010 09:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVq3bTJD0MKg for ; Wed, 21 Apr 2010 09:46:48 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 0CBA428C0D0 for ; Wed, 21 Apr 2010 09:22:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id DC2F2BB3F8E; Wed, 21 Apr 2010 09:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6RaJCkxhKR+8; Wed, 21 Apr 2010 09:22:05 -0700 (PDT) Received: from [10.96.18.220] (wlan39-022.mdr.icann.org [192.0.39.22]) by virtualized.org (Postfix) with ESMTP id C956CBB3F7E; Wed, 21 Apr 2010 09:22:05 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <046F43A8D79C794FA4733814869CDF070331E397@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Wed, 21 Apr 2010 09:21:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6946BF6E-50C3-4C89-95D6-FB4EC7466C5F@virtualized.org> References: <046F43A8D79C794FA4733814869CDF070331E333@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF070331E397@dul1wnexmb01.vcorp.ad.vrsn.com> To: "Hollenbeck, Scott" X-Mailer: Apple Mail (2.1078) Cc: ire@ietf.org Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 16:46:50 -0000 Scott, On Apr 21, 2010, at 4:11 AM, Hollenbeck, Scott wrote: > Primarily because there are working escrow implementations, such as = the > one developed to meet the requirements of the .COM agreement between > VeriSign and ICANN*, already in place. I think the issue is that there are multiple escrow implementations and = that it would probably be nice to standardize as that would likely = facilitate a bunch of good things. Regards, -drc Speaking personally From shollenbeck@verisign.com Wed Apr 21 10:55:24 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C6E3A6A03 for ; Wed, 21 Apr 2010 10:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.762 X-Spam-Level: X-Spam-Status: No, score=-5.762 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rePYGWOZIzgk for ; Wed, 21 Apr 2010 10:55:23 -0700 (PDT) Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by core3.amsl.com (Postfix) with ESMTP id 6D86E3A6CE2 for ; Wed, 21 Apr 2010 10:48:57 -0700 (PDT) Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o3LHfIJ1027068; Wed, 21 Apr 2010 13:41:18 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Apr 2010 13:48:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Apr 2010 13:48:45 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF070331E3DA@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <6946BF6E-50C3-4C89-95D6-FB4EC7466C5F@virtualized.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ire] Prodding by one of the chairs Thread-Index: Acrhbsz0TEjEXvcFSJ2Wvsb3Vv5ptgAC93Yg References: <046F43A8D79C794FA4733814869CDF070331E333@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF070331E397@dul1wnexmb01.vcorp.ad.vrsn.com> <6946BF6E-50C3-4C89-95D6-FB4EC7466C5F@virtualized.org> From: "Hollenbeck, Scott" To: "David Conrad" X-OriginalArrivalTime: 21 Apr 2010 17:48:45.0946 (UTC) FILETIME=[E3E955A0:01CAE17A] Cc: ire@ietf.org Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 17:55:24 -0000 > -----Original Message----- > From: David Conrad [mailto:drc@virtualized.org]=20 > Sent: Wednesday, April 21, 2010 12:22 PM > To: Hollenbeck, Scott > Cc: Francisco Arias; ire@ietf.org > Subject: Re: [ire] Prodding by one of the chairs >=20 > Scott, >=20 > On Apr 21, 2010, at 4:11 AM, Hollenbeck, Scott wrote: > > Primarily because there are working escrow implementations, such as=20 > > the one developed to meet the requirements of the .COM agreement=20 > > between VeriSign and ICANN*, already in place. >=20 > I think the issue is that there are multiple escrow=20 > implementations and that it would probably be nice to=20 > standardize as that would likely facilitate a bunch of good things. Maybe, but "nice" and "good" are relative terms. Scott From prvs=1721de7dc6=krista.papac@ironmountain.com Wed Apr 21 20:58:24 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CD783A6929 for ; Wed, 21 Apr 2010 20:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rx8WpzP6Zdqg for ; Wed, 21 Apr 2010 20:58:23 -0700 (PDT) Received: from kcsmtp01.ironmountain.com (kcsmtp01.ironmountain.com [216.229.158.20]) by core3.amsl.com (Postfix) with ESMTP id 478B03A6912 for ; Wed, 21 Apr 2010 20:58:22 -0700 (PDT) Received: from ([10.130.80.70]) by kcsmtp01.ironmountain.com with ESMTP with TLS id 6GMF5H1.105783671; Wed, 21 Apr 2010 22:58:09 -0500 Received: from NUMEVP11.na.imtn.com ([169.254.2.218]) by NUMEHTP03.na.imtn.com ([fe80::c85a:86e5:44d7:3d6d%10]) with mapi; Wed, 21 Apr 2010 23:58:09 -0400 From: "Papac, Krista" To: David Conrad , "Hollenbeck, Scott" Date: Wed, 21 Apr 2010 23:58:06 -0400 Thread-Topic: [ire] Prodding by one of the chairs Thread-Index: AcrhcjqVTMuRAVDmTuSaJudHCLhgeQAXHFcg Message-ID: <1CB60B47EE74294DAC9EE08837E617E29D8E2C64CE@NUMEVP11.na.imtn.com> References: <046F43A8D79C794FA4733814869CDF070331E333@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF070331E397@dul1wnexmb01.vcorp.ad.vrsn.com> <6946BF6E-50C3-4C89-95D6-FB4EC7466C5F@virtualized.org> In-Reply-To: <6946BF6E-50C3-4C89-95D6-FB4EC7466C5F@virtualized.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "ire@ietf.org" Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 03:58:24 -0000 I'm not sure what is meant by "multiple escrow implementations"=2E Escrow,= for the most part, is fairly consistent across Registries and is exactly t= he same for all depositing Registrars=2E I don't see why this consistency = can't continue into the future=2E=0D=0A=0D=0AKrista Papac =0D=0AIron Mounta= in Digital =0D=0A5530 Bandini Blvd =0D=0ABell, CA 90201 US =0D=0AHome Off= ice: +1=2E714=2E846=2E8780 =0D=0AMobile: +1=2E714=2E865=2E7655 =0D=0AFax: += 1=2E323=2E443=2E3573 =0D=0Akrista=2Epapac@ironmountain=2Ecom =0D=0A =0D=0A"= Software Escrow for Dummies" - order your complimentary copy today at www= =2Eironmountain=2Ecom/escrowfordummies=0D=0A =0D=0ANew Gartner Report: Succ= essful Software Escrow Requires Planning and Negotiation=0D=0AGartner advis= es: "It is also important that the licensee continue to track the software = vendor's financials and viability annually, because any signs of financial = problems would justify the cost of verification services=2E" Continue readi= ng the full report at: http://www=2Egartner=2Ecom/technology/media-products= /reprints/ironmountain/170569=2Ehtml=0D=0A=0D=0A-----Original Message-----= =0D=0AFrom: ire-bounces@ietf=2Eorg [mailto:ire-bounces@ietf=2Eorg] On Behal= f Of David Conrad=0D=0ASent: Wednesday, April 21, 2010 9:22 AM=0D=0ATo: Hol= lenbeck, Scott=0D=0ACc: ire@ietf=2Eorg=0D=0ASubject: Re: [ire] Prodding by = one of the chairs=0D=0A=0D=0AScott,=0D=0A=0D=0AOn Apr 21, 2010, at 4:11 AM,= Hollenbeck, Scott wrote:=0D=0A> Primarily because there are working escrow= implementations, such as the=0D=0A> one developed to meet the requirements= of the =2ECOM agreement between=0D=0A> VeriSign and ICANN*, already in pla= ce=2E=0D=0A=0D=0AI think the issue is that there are multiple escrow implem= entations and that it would probably be nice to standardize as that would l= ikely facilitate a bunch of good things=2E=0D=0A=0D=0ARegards,=0D=0A-drc=0D= =0ASpeaking personally=0D=0A=0D=0A_________________________________________= ______=0D=0Aire mailing list=0D=0Aire@ietf=2Eorg=0D=0Ahttps://www=2Eietf=2E= org/mailman/listinfo/ire=0D=0A-----------------------------------------=0D= =0AThe information contained in this email message and its attachments=0Ais= intended only for the private and confidential use of the=0Arecipient(s) n= amed above, unless the sender expressly agrees=0Aotherwise=2E=0D=0ATransmis= sion of email over the Internet is not a secure=0Acommunications medium=2E = If you are requesting or have requested the=0Atransmittal of personal data,= as defined in applicable privacy laws=0Aby means of email or in an attachm= ent to email, you must select a=0Amore secure alternate means of transmitta= l that supports your=0Aobligations to protect such personal data=2E =0D=0AI= f the reader of this message is not the intended recipient and/or=0Ayou hav= e received this email in error, you must take no action=0Abased on the info= rmation in this email and you are hereby notified=0Athat any dissemination,= misuse or copying or disclosure of this=0Acommunication is strictly prohib= ited=2E If you have received this=0Acommunication in error, please notify u= s immediately by email and=0Adelete the original message=2E From drc@virtualized.org Wed Apr 21 21:08:34 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 530893A6862 for ; Wed, 21 Apr 2010 21:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.11 X-Spam-Level: X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kW-QewXA4sa for ; Wed, 21 Apr 2010 21:08:33 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id A79603A6922 for ; Wed, 21 Apr 2010 21:08:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 8A87CBB7112; Wed, 21 Apr 2010 21:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CMV9cDS4uYs9; Wed, 21 Apr 2010 21:08:18 -0700 (PDT) Received: from [10.0.1.4] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 1F262BB70FC; Wed, 21 Apr 2010 21:08:18 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <1CB60B47EE74294DAC9EE08837E617E29D8E2C64CE@NUMEVP11.na.imtn.com> Date: Wed, 21 Apr 2010 21:08:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <776B9871-38FF-4226-BC71-A8643C6E1D89@virtualized.org> References: <046F43A8D79C794FA4733814869CDF070331E333@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF070331E397@dul1wnexmb01.vcorp.ad.vrsn.com> <6946BF6E-50C3-4C89-95D6-FB4EC7466C5F@virtualized.org> <1CB60B47EE74294DAC9EE08837E617E29D8E2C64CE@NUMEVP11.na.imtn.com> To: "Papac, Krista" X-Mailer: Apple Mail (2.1078) Cc: ire@ietf.org Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 04:08:34 -0000 Krista, Does "this consistency" include present and/or future cases where = ccTLDs, address registries, etc. are escrowing data? Regards, -drc On Apr 21, 2010, at 8:58 PM, Papac, Krista wrote: > I'm not sure what is meant by "multiple escrow implementations". = Escrow, for the most part, is fairly consistent across Registries and is = exactly the same for all depositing Registrars. I don't see why this = consistency can't continue into the future. >=20 > Krista Papac=20 > Iron Mountain Digital=20 > 5530 Bandini Blvd=20 > Bell, CA 90201 US=20 > Home Office: +1.714.846.8780=20 > Mobile: +1.714.865.7655=20 > Fax: +1.323.443.3573=20 > krista.papac@ironmountain.com=20 >=20 > "Software Escrow for Dummies" - order your complimentary copy today at = www.ironmountain.com/escrowfordummies >=20 > New Gartner Report: Successful Software Escrow Requires Planning and = Negotiation > Gartner advises: "It is also important that the licensee continue to = track the software vendor's financials and viability annually, because = any signs of financial problems would justify the cost of verification = services." Continue reading the full report at: = http://www.gartner.com/technology/media-products/reprints/ironmountain/170= 569.html >=20 > -----Original Message----- > From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On Behalf Of = David Conrad > Sent: Wednesday, April 21, 2010 9:22 AM > To: Hollenbeck, Scott > Cc: ire@ietf.org > Subject: Re: [ire] Prodding by one of the chairs >=20 > Scott, >=20 > On Apr 21, 2010, at 4:11 AM, Hollenbeck, Scott wrote: >> Primarily because there are working escrow implementations, such as = the >> one developed to meet the requirements of the .COM agreement between >> VeriSign and ICANN*, already in place. >=20 > I think the issue is that there are multiple escrow implementations = and that it would probably be nice to standardize as that would likely = facilitate a bunch of good things. >=20 > Regards, > -drc > Speaking personally >=20 > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire > ----------------------------------------- > The information contained in this email message and its attachments > is intended only for the private and confidential use of the > recipient(s) named above, unless the sender expressly agrees > otherwise. > Transmission of email over the Internet is not a secure > communications medium. If you are requesting or have requested the > transmittal of personal data, as defined in applicable privacy laws > by means of email or in an attachment to email, you must select a > more secure alternate means of transmittal that supports your > obligations to protect such personal data.=20 > If the reader of this message is not the intended recipient and/or > you have received this email in error, you must take no action > based on the information in this email and you are hereby notified > that any dissemination, misuse or copying or disclosure of this > communication is strictly prohibited. If you have received this > communication in error, please notify us immediately by email and > delete the original message. >=20 From prvs=1721de7dc6=krista.papac@ironmountain.com Wed Apr 21 21:14:14 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 123903A6AE0 for ; Wed, 21 Apr 2010 21:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hi2TjLHJKe3B for ; Wed, 21 Apr 2010 21:14:11 -0700 (PDT) Received: from kcsmtp01.ironmountain.com (kcsmtp01.ironmountain.com [216.229.158.20]) by core3.amsl.com (Postfix) with ESMTP id 427B93A6ACA for ; Wed, 21 Apr 2010 21:14:11 -0700 (PDT) Received: from ([10.130.80.70]) by kcsmtp01.ironmountain.com with ESMTP with TLS id 6GMF5H1.105786346; Wed, 21 Apr 2010 23:13:58 -0500 Received: from NUMEVP11.na.imtn.com ([169.254.2.218]) by NUMEHTP03.na.imtn.com ([fe80::c85a:86e5:44d7:3d6d%10]) with mapi; Thu, 22 Apr 2010 00:13:58 -0400 From: "Papac, Krista" To: David Conrad Date: Thu, 22 Apr 2010 00:13:56 -0400 Thread-Topic: [ire] Prodding by one of the chairs Thread-Index: Acrh0XUPMkmM5nlQS8+uYr15j5/OegAAC1RQ Message-ID: <1CB60B47EE74294DAC9EE08837E617E29D8E2C64CF@NUMEVP11.na.imtn.com> References: <046F43A8D79C794FA4733814869CDF070331E333@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF070331E397@dul1wnexmb01.vcorp.ad.vrsn.com> <6946BF6E-50C3-4C89-95D6-FB4EC7466C5F@virtualized.org> <1CB60B47EE74294DAC9EE08837E617E29D8E2C64CE@NUMEVP11.na.imtn.com> <776B9871-38FF-4226-BC71-A8643C6E1D89@virtualized.org> In-Reply-To: <776B9871-38FF-4226-BC71-A8643C6E1D89@virtualized.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ire@ietf.org" Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 04:14:14 -0000 We currently have some ccTLD customers and yes I am including them. In res= pect to address registries, or IDNs (I'm guessing you are asking about them= too), there currently aren't specs for these situations but that shouldn't= prevent us from creating a spec for where consistency is required for thes= e additional data fields. =20 Krista Papac=20 Iron Mountain Digital=20 5530 Bandini Blvd=20 Bell, CA 90201 US=20 Home Office: +1.714.846.8780=20 Mobile: +1.714.865.7655=20 Fax: +1.323.443.3573=20 krista.papac@ironmountain.com=20 =20 "Software Escrow for Dummies" - order your complimentary copy today at www.= ironmountain.com/escrowfordummies =20 New Gartner Report: Successful Software Escrow Requires Planning and Negoti= ation Gartner advises: "It is also important that the licensee continue to track = the software vendor's financials and viability annually, because any signs = of financial problems would justify the cost of verification services." Con= tinue reading the full report at: http://www.gartner.com/technology/media-p= roducts/reprints/ironmountain/170569.html -----Original Message----- From: David Conrad [mailto:drc@virtualized.org]=20 Sent: Wednesday, April 21, 2010 9:08 PM To: Papac, Krista Cc: ire@ietf.org Subject: Re: [ire] Prodding by one of the chairs Krista, Does "this consistency" include present and/or future cases where ccTLDs, a= ddress registries, etc. are escrowing data? Regards, -drc On Apr 21, 2010, at 8:58 PM, Papac, Krista wrote: > I'm not sure what is meant by "multiple escrow implementations". Escrow,= for the most part, is fairly consistent across Registries and is exactly t= he same for all depositing Registrars. I don't see why this consistency ca= n't continue into the future. >=20 > Krista Papac=20 > Iron Mountain Digital=20 > 5530 Bandini Blvd=20 > Bell, CA 90201 US=20 > Home Office: +1.714.846.8780=20 > Mobile: +1.714.865.7655=20 > Fax: +1.323.443.3573=20 > krista.papac@ironmountain.com=20 >=20 > "Software Escrow for Dummies" - order your complimentary copy today at ww= w.ironmountain.com/escrowfordummies >=20 > New Gartner Report: Successful Software Escrow Requires Planning and Nego= tiation > Gartner advises: "It is also important that the licensee continue to trac= k the software vendor's financials and viability annually, because any sign= s of financial problems would justify the cost of verification services." C= ontinue reading the full report at: http://www.gartner.com/technology/media= -products/reprints/ironmountain/170569.html >=20 > -----Original Message----- > From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On Behalf Of Dav= id Conrad > Sent: Wednesday, April 21, 2010 9:22 AM > To: Hollenbeck, Scott > Cc: ire@ietf.org > Subject: Re: [ire] Prodding by one of the chairs >=20 > Scott, >=20 > On Apr 21, 2010, at 4:11 AM, Hollenbeck, Scott wrote: >> Primarily because there are working escrow implementations, such as the >> one developed to meet the requirements of the .COM agreement between >> VeriSign and ICANN*, already in place. >=20 > I think the issue is that there are multiple escrow implementations and t= hat it would probably be nice to standardize as that would likely facilitat= e a bunch of good things. >=20 > Regards, > -drc > Speaking personally >=20 > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire > ----------------------------------------- > The information contained in this email message and its attachments > is intended only for the private and confidential use of the > recipient(s) named above, unless the sender expressly agrees > otherwise. > Transmission of email over the Internet is not a secure > communications medium. If you are requesting or have requested the > transmittal of personal data, as defined in applicable privacy laws > by means of email or in an attachment to email, you must select a > more secure alternate means of transmittal that supports your > obligations to protect such personal data.=20 > If the reader of this message is not the intended recipient and/or > you have received this email in error, you must take no action > based on the information in this email and you are hereby notified > that any dissemination, misuse or copying or disclosure of this > communication is strictly prohibited. If you have received this > communication in error, please notify us immediately by email and > delete the original message. >=20 From francisco.arias@icann.org Wed Apr 21 21:26:36 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519CB3A6AEF for ; Wed, 21 Apr 2010 21:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.267 X-Spam-Level: X-Spam-Status: No, score=-5.267 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0JSb+uK8U27 for ; Wed, 21 Apr 2010 21:26:34 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id D95BB3A6AE0 for ; Wed, 21 Apr 2010 21:26:34 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Wed, 21 Apr 2010 21:26:25 -0700 From: Francisco Arias To: Krista Papac , David Conrad , "Hollenbeck, Scott" Date: Wed, 21 Apr 2010 21:26:23 -0700 Thread-Topic: [ire] Prodding by one of the chairs Thread-Index: AcrhcjqVTMuRAVDmTuSaJudHCLhgeQAXHFcgAAFSvEY= Message-ID: In-Reply-To: <1CB60B47EE74294DAC9EE08837E617E29D8E2C64CE@NUMEVP11.na.imtn.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7F51DFF38A7franciscoariasicannorg_" MIME-Version: 1.0 Cc: "ire@ietf.org" Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 04:26:36 -0000 --_000_C7F51DFF38A7franciscoariasicannorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Currently each gTLD has its own data escrow format, for example, there are = ones that use colon separated data, there are others that use XML and other= s that use SQL dumps. JP also uses XML. Even those that use XML, that are the majority, do not necessarily have the= same spec. __ Francisco On 4/21/10 8:58 PM, "Krista Papac" wrote: I'm not sure what is meant by "multiple escrow implementations". Escrow, f= or the most part, is fairly consistent across Registries and is exactly the= same for all depositing Registrars. I don't see why this consistency can'= t continue into the future. Krista Papac Iron Mountain Digital 5530 Bandini Blvd Bell, CA 90201 US Home Office: +1.714.846.8780 Mobile: +1.714.865.7655 Fax: +1.323.443.3573 krista.papac@ironmountain.com "Software Escrow for Dummies" - order your complimentary copy today at www.= ironmountain.com/escrowfordummies New Gartner Report: Successful Software Escrow Requires Planning and Negoti= ation Gartner advises: "It is also important that the licensee continue to track = the software vendor's financials and viability annually, because any signs = of financial problems would justify the cost of verification services." Con= tinue reading the full report at: http://www.gartner.com/technology/media-p= roducts/reprints/ironmountain/170569.html -----Original Message----- From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On Behalf Of David= Conrad Sent: Wednesday, April 21, 2010 9:22 AM To: Hollenbeck, Scott Cc: ire@ietf.org Subject: Re: [ire] Prodding by one of the chairs Scott, On Apr 21, 2010, at 4:11 AM, Hollenbeck, Scott wrote: > Primarily because there are working escrow implementations, such as the > one developed to meet the requirements of the .COM agreement between > VeriSign and ICANN*, already in place. I think the issue is that there are multiple escrow implementations and tha= t it would probably be nice to standardize as that would likely facilitate = a bunch of good things. Regards, -drc Speaking personally _______________________________________________ ire mailing list ire@ietf.org https://www.ietf.org/mailman/listinfo/ire ----------------------------------------- The information contained in this email message and its attachments is intended only for the private and confidential use of the recipient(s) named above, unless the sender expressly agrees otherwise. Transmission of email over the Internet is not a secure communications medium. If you are requesting or have requested the transmittal of personal data, as defined in applicable privacy laws by means of email or in an attachment to email, you must select a more secure alternate means of transmittal that supports your obligations to protect such personal data. If the reader of this message is not the intended recipient and/or you have received this email in error, you must take no action based on the information in this email and you are hereby notified that any dissemination, misuse or copying or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the original message. _______________________________________________ ire mailing list ire@ietf.org https://www.ietf.org/mailman/listinfo/ire --_000_C7F51DFF38A7franciscoariasicannorg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [ire] Prodding by one of the chairs Currently each gTLD has= its own data escrow format, for example, there are ones that use colon sep= arated data, there are others that use XML and others that use SQL dumps. J= P also uses XML.

Even those that use XML, that are the majority, do not necessarily have the= same spec.

__
Francisco



On 4/21/10 8:58 PM, "Krista Papac" <Krista.Papac@ironmountain.com> wrote:

I'm not sure what is meant by "multiple escrow implementations"= ;.  Escrow, for the most part, is fairly consistent across Registries = and is exactly the same for all depositing Registrars.  I don't see wh= y this consistency can't continue into the future.

Krista Papac
Iron Mountain Digital
5530 Bandini Blvd
Bell, CA  90201  US
Home Office: +1.714.846.8780
Mobile: +1.714.865.7655
Fax: +1.323.443.3573
krista.papac@ironmountain.com=

"Software Escrow for Dummies" - order your complimentary copy tod= ay at www.ironmountain.com/escrowfordummies

New Gartner Report: Successful Software Escrow Requires Planning and Negoti= ation
Gartner advises: "It is also important that the licensee continue to t= rack the software vendor's financials and viability annually, because any s= igns of financial problems would justify the cost of verification services.= " Continue reading the full report at: http://www.= gartner.com/technology/media-products/reprints/ironmountain/170569.html=

-----Original Message-----
From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On Behalf Of= David Conrad
Sent: Wednesday, April 21, 2010 9:22 AM
To: Hollenbeck, Scott
Cc: ire@ietf.org
Subject: Re: [ire] Prodding by one of the chairs

Scott,

On Apr 21, 2010, at 4:11 AM, Hollenbeck, Scott wrote:
> Primarily because there are working escrow implementations, such as th= e
> one developed to meet the requirements of the .COM agreement between > VeriSign and ICANN*, already in place.

I think the issue is that there are multiple escrow implementations and tha= t it would probably be nice to standardize as that would likely facilitate = a bunch of good things.

Regards,
-drc
Speaking personally

_______________________________________________
ire mailing list
ire@ietf.org
https://www.ietf.org/= mailman/listinfo/ire
-----------------------------------------
The information contained in this email message and its attachments
is intended only for the private and confidential use of the
recipient(s) named above, unless the sender expressly agrees
otherwise.
Transmission of email over the Internet is not a secure
communications medium. If you are requesting or have requested the
transmittal of personal data, as defined in applicable privacy laws
by means of email or in an attachment to email, you must select a
more secure alternate means of transmittal that supports your
obligations to protect such personal data.
If the reader of this message is not the intended recipient and/or
you have received this email in error, you must take no action
based on the information in this email and you are hereby notified
that any dissemination, misuse or copying or disclosure of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by email and
delete the original message.
_______________________________________________
ire mailing list
ire@ietf.org
https://www.ietf.org/= mailman/listinfo/ire

--_000_C7F51DFF38A7franciscoariasicannorg_-- From drc@virtualized.org Wed Apr 21 21:29:17 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09DEB3A69F2 for ; Wed, 21 Apr 2010 21:29:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koZm7-WoDwHh for ; Wed, 21 Apr 2010 21:29:16 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 4C7BE3A6940 for ; Wed, 21 Apr 2010 21:29:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 0D717BB7383; Wed, 21 Apr 2010 21:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yo-2iazpnxNc; Wed, 21 Apr 2010 21:29:04 -0700 (PDT) Received: from [10.0.1.4] (c-24-130-210-17.hsd1.ca.comcast.net [24.130.210.17]) by virtualized.org (Postfix) with ESMTP id 07D26BB736F; Wed, 21 Apr 2010 21:29:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <1CB60B47EE74294DAC9EE08837E617E29D8E2C64CF@NUMEVP11.na.imtn.com> Date: Wed, 21 Apr 2010 21:29:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <82F87B34-C652-44BB-95CE-0C25659AB3F3@virtualized.org> References: <046F43A8D79C794FA4733814869CDF070331E333@dul1wnexmb01.vcorp.ad.vrsn.com> <046F43A8D79C794FA4733814869CDF070331E397@dul1wnexmb01.vcorp.ad.vrsn.com> <6946BF6E-50C3-4C89-95D6-FB4EC7466C5F@virtualized.org> <1CB60B47EE74294DAC9EE08837E617E29D8E2C64CE@NUMEVP11.na.imtn.com> <776B9871-38FF-4226-BC71-A8643C6E1D89@virtualized.org> <1CB60B47EE74294DAC9EE08837E617E29D8E2C64CF@NUMEVP11.na.imtn.com> To: "Papac, Krista" X-Mailer: Apple Mail (2.1078) Cc: "ire@ietf.org" Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 04:29:17 -0000 Krista, On Apr 21, 2010, at 9:13 PM, Papac, Krista wrote: > there currently aren't specs for these situations but that shouldn't = prevent us from creating a spec for where consistency is required for = these additional data fields. =20 I believe that's the point of the working group. Regards, -drc From prvs=1721de7dc6=krista.papac@ironmountain.com Wed Apr 21 21:41:43 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 962D23A679F for ; Wed, 21 Apr 2010 21:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.649, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_NONELEMENT_30_40=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKX-PtFLNCly for ; Wed, 21 Apr 2010 21:41:33 -0700 (PDT) Received: from kcsmtp01.ironmountain.com (kcsmtp01.ironmountain.com [216.229.158.20]) by core3.amsl.com (Postfix) with ESMTP id 94BEF3A6933 for ; Wed, 21 Apr 2010 21:41:33 -0700 (PDT) Received: from ([10.130.80.69]) by kcsmtp01.ironmountain.com with ESMTP with TLS id 6GMF5H1.105790654; Wed, 21 Apr 2010 23:40:57 -0500 Received: from NUMEVP11.na.imtn.com ([169.254.2.218]) by NUMEHTP02.na.imtn.com ([fe80::41a8:a9a7:1cd1:d3c6%10]) with mapi; Thu, 22 Apr 2010 00:40:57 -0400 From: "Papac, Krista" To: Francisco Arias , David Conrad , "Hollenbeck, Scott" Date: Thu, 22 Apr 2010 00:40:55 -0400 Thread-Topic: [ire] Prodding by one of the chairs Thread-Index: AcrhcjqVTMuRAVDmTuSaJudHCLhgeQAXHFcgAAFSvEYAADuREA== Message-ID: <1CB60B47EE74294DAC9EE08837E617E29D8E2C64D1@NUMEVP11.na.imtn.com> References: <1CB60B47EE74294DAC9EE08837E617E29D8E2C64CE@NUMEVP11.na.imtn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_1CB60B47EE74294DAC9EE08837E617E29D8E2C64D1NUMEVP11naimt_" Cc: "ire@ietf.org" Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 04:41:43 -0000 --_000_1CB60B47EE74294DAC9EE08837E617E29D8E2C64D1NUMEVP11naimt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Currently Iron Mountain escrows for 13 of the 16 gTLDs that are required to= deposit=2E Of those 13, which comprise the majority of both registries an= d domain names registered, 2 escrow in CSV and 11 in XML=2E=0D=0AAdditional= ly, there are well over 800 registrars escrowing with Iron Mountain and ALL= of them escrow in CSV=2E=0D=0AI agree that the registry specs vary, but no= t that significantly and the variance is largely due to uncoordinated writi= ng of the specs rather than data requirements=2E=0D=0AThe registrar spec wa= s thought out in advance and therefore they all have the same spec=2E=0D=0A= =0D=0A=0D=0AKrista Papac=0D=0AIron Mountain Digital=0D=0A5530 Bandini Blvd= =0D=0ABell, CA 90201 US=0D=0AHome Office: +1=2E714=2E846=2E8780=0D=0AMobi= le: +1=2E714=2E865=2E7655=0D=0AFax: +1=2E323=2E443=2E3573=0D=0Akrista=2Epap= ac@ironmountain=2Ecom=0D=0A=0D=0A= "Software Escrow for Dummies" - order your complimentary copy today at www=2Eironmountain=2Ecom/esc= rowfordummies=0D=0A=0D=0A= New Gartner Report: Successful Software Escrow Requires Planning and Negoti= ation=0D=0AGartner advises: "It is also important that the licensee continu= e to track the software vendor's financials and viability annually, because= any signs of financial problems would justify the cost of verification ser= vices=2E" Continue reading the full report at: http://www=2Egartner=2Ecom/t= echnology/media-products/reprints/ironmountain/170569=2Ehtml=0D=0A=0D=0A___= _____________________________=0D=0AFrom: Francisco Arias [mailto:francisco= =2Earias@icann=2Eorg]=0D=0ASent: Wednesday, April 21, 2010 9:26 PM=0D=0ATo:= Papac, Krista; David Conrad; Hollenbeck, Scott=0D=0ACc: ire@ietf=2Eorg=0D= =0ASubject: Re: [ire] Prodding by one of the chairs=0D=0A=0D=0ACurrently ea= ch gTLD has its own data escrow format, for example, there are ones that us= e colon separated data, there are others that use XML and others that use S= QL dumps=2E JP also uses XML=2E=0D=0A=0D=0AEven those that use XML, that ar= e the majority, do not necessarily have the same spec=2E=0D=0A=0D=0A__=0D= =0AFrancisco=0D=0A=0D=0A=0D=0A=0D=0AOn 4/21/10 8:58 PM, "Krista Papac" wrote:=0D=0AI'm not sure what is meant by "= multiple escrow implementations"=2E Escrow, for the most part, is fairly c= onsistent across Registries and is exactly the same for all depositing Regi= strars=2E I don't see why this consistency can't continue into the future= =2E=0D=0A=0D=0AKrista Papac=0D=0AIron Mountain Digital=0D=0A5530 Bandini Bl= vd=0D=0ABell, CA 90201 US=0D=0AHome Office: +1=2E714=2E846=2E8780=0D=0AMo= bile: +1=2E714=2E865=2E7655=0D=0AFax: +1=2E323=2E443=2E3573=0D=0Akrista=2Ep= apac@ironmountain=2Ecom=0D=0A=0D=0A"Software Escrow for Dummies" - order yo= ur complimentary copy today at www=2Eironmountain=2Ecom/escrowfordummies=0D= =0A=0D=0ANew Gartner Report: Successful Software Escrow Requires Planning a= nd Negotiation=0D=0AGartner advises: "It is also important that the license= e continue to track the software vendor's financials and viability annually= , because any signs of financial problems would justify the cost of verific= ation services=2E" Continue reading the full report at: http://www=2Egartne= r=2Ecom/technology/media-products/reprints/ironmountain/170569=2Ehtml=0D=0A= =0D=0A-----Original Message-----=0D=0AFrom: ire-bounces@ietf=2Eorg [mailto:= ire-bounces@ietf=2Eorg] On Behalf Of David Conrad=0D=0ASent: Wednesday, Apr= il 21, 2010 9:22 AM=0D=0ATo: Hollenbeck, Scott=0D=0ACc: ire@ietf=2Eorg=0D= =0ASubject: Re: [ire] Prodding by one of the chairs=0D=0A=0D=0AScott,=0D=0A= =0D=0AOn Apr 21, 2010, at 4:11 AM, Hollenbeck, Scott wrote:=0D=0A> Primaril= y because there are working escrow implementations, such as the=0D=0A> one = developed to meet the requirements of the =2ECOM agreement between=0D=0A> V= eriSign and ICANN*, already in place=2E=0D=0A=0D=0AI think the issue is tha= t there are multiple escrow implementations and that it would probably be n= ice to standardize as that would likely facilitate a bunch of good things= =2E=0D=0A=0D=0ARegards,=0D=0A-drc=0D=0ASpeaking personally=0D=0A=0D=0A_____= __________________________________________=0D=0Aire mailing list=0D=0Aire@i= etf=2Eorg=0D=0Ahttps://www=2Eietf=2Eorg/mailman/listinfo/ire=0D=0A---------= --------------------------------=0D=0AThe information contained in this ema= il message and its attachments=0D=0Ais intended only for the private and co= nfidential use of the=0D=0Arecipient(s) named above, unless the sender expr= essly agrees=0D=0Aotherwise=2E=0D=0ATransmission of email over the Internet= is not a secure=0D=0Acommunications medium=2E If you are requesting or hav= e requested the=0D=0Atransmittal of personal data, as defined in applicable= privacy laws=0D=0Aby means of email or in an attachment to email, you must= select a=0D=0Amore secure alternate means of transmittal that supports you= r=0D=0Aobligations to protect such personal data=2E=0D=0AIf the reader of t= his message is not the intended recipient and/or=0D=0Ayou have received thi= s email in error, you must take no action=0D=0Abased on the information in = this email and you are hereby notified=0D=0Athat any dissemination, misuse = or copying or disclosure of this=0D=0Acommunication is strictly prohibited= =2E If you have received this=0D=0Acommunication in error, please notify us= immediately by email and=0D=0Adelete the original message=2E=0D=0A________= _______________________________________=0D=0Aire mailing list=0D=0Aire@ietf= =2Eorg=0D=0Ahttps://www=2Eietf=2Eorg/mailman/listinfo/ire=0D=0A=0D=0A=0D=0A= -----------------------------------------=0D=0AThe information contained in= this email message and its attachments=0Ais intended only for the private = and confidential use of the=0Arecipient(s) named above, unless the sender e= xpressly agrees=0Aotherwise=2E=0D=0ATransmission of email over the Internet= is not a secure=0Acommunications medium=2E If you are requesting or have r= equested the=0Atransmittal of personal data, as defined in applicable priva= cy laws=0Aby means of email or in an attachment to email, you must select a= =0Amore secure alternate means of transmittal that supports your=0Aobligati= ons to protect such personal data=2E =0D=0AIf the reader of this message is= not the intended recipient and/or=0Ayou have received this email in error,= you must take no action=0Abased on the information in this email and you a= re hereby notified=0Athat any dissemination, misuse or copying or disclosur= e of this=0Acommunication is strictly prohibited=2E If you have received th= is=0Acommunication in error, please notify us immediately by email and=0Ade= lete the original message=2E --_000_1CB60B47EE74294DAC9EE08837E617E29D8E2C64D1NUMEVP11naimt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0ARe: [ire] Proddi= ng by one of the chairs=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=0D=0A=0D=0A
=0D=0A=0D=0A

= Currently Iron Mountain= =0D=0Aescrows for 13 of the 16 gTLDs that are required to deposit=2E  = Of those 13,=0D=0Awhich comprise the majority of both registries and domain= names registered, 2=0D=0Aescrow in CSV and 11 in XML=2E  <= /span>

=0D=0A=0D=0A

Additionally, there are well over 800=0D=0Aregistrars escrowing = with Iron= =0D=0A Mountain and = ALL of them=0D=0Aescrow in CSV=2E

=0D=0A=0D=0A<= p class=3DMsoNormal>I agree that the re= gistry specs vary, but not=0D=0Athat significantly and the variance is larg= ely due to uncoordinated writing of the=0D=0Aspecs rather than data require= ments=2E

=0D=0A=0D=0A

The registrar spec was thought out in=0D=0Aa= dvance and therefore they all have the same spec=2E 

=0D=0A=0D=0A

 

=0D=0A=0D=0A

<= font size=3D2 color=3Dnavy face=3DArial> 

=0D= =0A=0D=0A
=0D=0A=0D=0A

Krista Papac
=0D=0AIron= Mountain Digital
=0D=0A5530 Ban= dini=0D=0A Blvd<= /ns0:address>
=0D=0ABell, CA=   90201  <= font color=3Dnavy>US
=0D=0AHome Office: +1=2E714=2E846=2E8780 =0D=0AMobi= le: +1=2E714=2E865=2E7655<= /span>
=0D=0AFax: +1=2E323=2E443=2E3573
=0D=0Akrista=2Epapac@ironmountain=2Ecom =0D=0A=0D=0A

 <= /o:p>

=0D=0A=0D=0A

“Software Escrow for Dummies”<= span style=3D'color:navy;font-weight:normal'>=0D=0A- order your complimenta= ry copy today at <= a href=3D"http://www=2Eironmountain=2Ecom/escrowfordummies"=0D=0Atitle=3D"h= ttp://ironmountain=2Ecom/escrowfordummies">www=2Eironmountain=2Ecom/escrowfordummi= es

=0D=0A=0D=0A

 

=0D=0A=0D=0A

New= =0D=0AGartner Report: Successful Software Escrow Requires Planning and Nego= tiation

=0D=0A=0D=0A

Gartner advises: “It is also=0D=0Aimportant= that the licensee continue to track the software vendor’s=0D=0Afinan= cials and viability annually, because any signs of financial problems=0D=0A= would justify the cost of verification services=2E” Continue reading = the=0D=0Afull report at: http://www=2Egartner= =2Ecom/technology/media-products/reprints/ironmountain/170569=2Ehtml=

=0D=0A=0D=0A
=0D=0A=0D= =0A

 

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D= =0A=0D=0A

From: Francisco Arias=0D=0A[mailto:francisco=2Earias@= icann=2Eorg]
=0D=0ASent:= Wednesday, April 21, 2010=0D=0A9:26 PM
=0D=0ATo: Papac, Krista; David Conrad;=0D=0AHollenbeck, Scot= t
=0D=0ACc: ire@ietf=2Eor= g
=0D=0ASubject: Re: [ire= ] Prodding by one=0D=0Aof the chairs

=0D=0A=0D= =0A
=0D=0A=0D=0A

 

=0D=0A=0D=0A

<= font size=3D3 face=3DArial>Currently each gTLD has its own data=0D=0Aescrow format, for exam= ple, there are ones that use colon separated data, there=0D=0Aare others th= at use XML and others that use SQL dumps=2E JP also uses XML=2E
=0D=0A=0D=0AEven those that use XML, that are the majority, do not necessarily = have the=0D=0Asame spec=2E
=0D=0A
=0D=0A__
=0D=0AFrancisco
=0D= =0A
=0D=0A
=0D=0A
=0D=0AOn 4/21/10 8:58 PM, "Krista Papac&quo= t; <Krista=2EPapac@ir= onmountain=2Ecom>=0D=0Awrote:

=0D=0A=0D= =0A

I'm not= sure what is meant by=0D=0A"multiple escrow implementations"=2E =  Escrow, for the most part,=0D=0Ais fairly consistent across Registrie= s and is exactly the same for all=0D=0Adepositing Registrars=2E  I don= 't see why this consistency can't continue=0D=0Ainto the future=2E
=0D= =0A
=0D=0AKrista Papac
=0D=0AIron Mountain Digital
=0D=0A5530 Band= ini Blvd
=0D=0ABell, CA  90201  US
=0D=0AHome Office: +1=2E= 714=2E846=2E8780
=0D=0AMobile: +1=2E714=2E865=2E7655
=0D=0AFax: +1=2E= 323=2E443=2E3573
=0D=0Akri= sta=2Epapac@ironmountain=2Ecom
=0D=0A
=0D=0A"Software Escrow= for Dummies" - order your complimentary copy today=0D=0Aat www=2Eiron= mountain=2Ecom/escrowfordummies
=0D=0A
=0D=0ANew Gartner Report: Succ= essful Software Escrow Requires Planning and=0D=0ANegotiation
=0D=0AGart= ner advises: "It is also important that the licensee continue to track= =0D=0Athe software vendor's financials and viability annually, because any = signs of=0D=0Afinancial problems would justify the cost of verification ser= vices=2E"=0D=0AContinue reading the full report at: http://www=2Egartner=2Ecom/technology/media-products/reprints/= ironmountain/170569=2Ehtml
=0D=0A
=0D=0A-----Original Message----= -
=0D=0AFrom: ire-bounces@ietf=2Eorg<= /a> [mailto:ire-bounces@ietf= =2Eorg] On Behalf=0D=0AOf David Conrad
=0D=0ASent: Wednesday, April = 21, 2010 9:22 AM
=0D=0ATo: Hollenbeck, Scott
=0D=0ACc: ire@ietf=2Eorg
=0D=0ASubject: Re: [ire] Prodding by one= of the chairs
=0D=0A
=0D=0AScott,
=0D=0A
=0D=0AOn Apr 21, 2010= , at 4:11 AM, Hollenbeck, Scott wrote:
=0D=0A> Primarily because ther= e are working escrow implementations, such as the
=0D=0A> one develop= ed to meet the requirements of the =2ECOM agreement between
=0D=0A> V= eriSign and ICANN*, already in place=2E
=0D=0A
=0D=0AI think the issu= e is that there are multiple escrow implementations and that it=0D=0Awould = probably be nice to standardize as that would likely facilitate a bunch=0D= =0Aof good things=2E
=0D=0A
=0D=0ARegards,
=0D=0A-drc
=0D=0ASpe= aking personally
=0D=0A
=0D=0A_______________________________________= ________
=0D=0Aire mailing list
=0D=0Aire@= ietf=2Eorg
=0D=0Ahttps://www=2Eietf=2Eorg/mailman/listinfo/ire
=0D=0A---------= --------------------------------
=0D=0AThe information contained in this= email message and its attachments
=0D=0Ais intended only for the privat= e and confidential use of the
=0D=0Arecipient(s) named above, unless the= sender expressly agrees
=0D=0Aotherwise=2E
=0D=0ATransmission of ema= il over the Internet is not a secure
=0D=0Acommunications medium=2E If y= ou are requesting or have requested the
=0D=0Atransmittal of personal da= ta, as defined in applicable privacy laws
=0D=0Aby means of email or in = an attachment to email, you must select a
=0D=0Amore secure alternate me= ans of transmittal that supports your
=0D=0Aobligations to protect such = personal data=2E
=0D=0AIf the reader of this message is not the intended= recipient and/or
=0D=0Ayou have received this email in error, you must = take no action
=0D=0Abased on the information in this email and you are = hereby notified
=0D=0Athat any dissemination, misuse or copying or discl= osure of this
=0D=0Acommunication is strictly prohibited=2E If you have = received this
=0D=0Acommunication in error, please notify us immediately= by email and
=0D=0Adelete the original message=2E
=0D=0A____________= ___________________________________
=0D=0Aire mailing list
=0D=0Aire@ietf=2Eorg
=0D=0Ahttps://www=2Eietf=2Eorg/mailman/listin= fo/ire

=0D=0A=0D=0A
=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A

=0D=0A

=0D=0AThe information contained in this email message and its attachm= ents is intended only for the private and confidential use of the recipient= (s) named above, unless the sender expressly agrees otherwise=2E=0D=0ATrans= mission of email over the Internet is not a secure communications medium=2E= If you are requesting or have requested the transmittal of personal data, = as defined in applicable privacy laws by means of email or in an attachment= to email, you must select a more secure alternate means of transmittal tha= t supports your obligations to protect such personal data=2E =0D=0AIf the r= eader of this message is not the intended recipient and/or you have receive= d this email in error, you must take no action based on the information in = this email and you are hereby notified that any dissemination, misuse or co= pying or disclosure of this communication is strictly prohibited=2E If you = have received this communication in error, please notify us immediately by = email and delete the original message=2E=0D=0A

--_000_1CB60B47EE74294DAC9EE08837E617E29D8E2C64D1NUMEVP11naimt_-- From francisco.arias@icann.org Wed Apr 21 21:57:53 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32D243A681F for ; Wed, 21 Apr 2010 21:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.135 X-Spam-Level: X-Spam-Status: No, score=-5.135 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgjGBgigeHrY for ; Wed, 21 Apr 2010 21:57:51 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id CF0423A657C for ; Wed, 21 Apr 2010 21:57:51 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Wed, 21 Apr 2010 21:57:42 -0700 From: Francisco Arias To: Krista Papac , David Conrad , "Hollenbeck, Scott" Date: Wed, 21 Apr 2010 21:57:40 -0700 Thread-Topic: [ire] Prodding by one of the chairs Thread-Index: AcrhcjqVTMuRAVDmTuSaJudHCLhgeQAXHFcgAAFSvEYAADuREAAA3CEy Message-ID: In-Reply-To: <1CB60B47EE74294DAC9EE08837E617E29D8E2C64D1@NUMEVP11.na.imtn.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ire@ietf.org" Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 04:57:53 -0000 Krista, you are right about the unified CSV spec for ICANN accredited registrars. In fact, the current draft spec for new gTLDs that I put in Internet-Draft format for this group is based on the registrar's one, up to certain point. As it has been mentioned before, the idea of forming this group is to defin= e a spec that could be used by gTLDs, ccTLDs and maybe other types of registries. Storing the data with a data escrow agent is just the fist step. The ultimate goal is to be able to do something useful with the data should the need be. Having a well defined and unified spec will certainly help on that regard. __=20 Francisco On 4/21/10 9:40 PM, "Krista Papac" wrote: > Currently Iron Mountain escrows for 13 of the 16 gTLDs that are required = to > deposit. Of those 13, which comprise the majority of both registries and > domain names registered, 2 escrow in CSV and 11 in XML. > Additionally, there are well over 800 registrars escrowing with Iron Moun= tain > and ALL of them escrow in CSV. > I agree that the registry specs vary, but not that significantly and the > variance is largely due to uncoordinated writing of the specs rather than= data > requirements. > The registrar spec was thought out in advance and therefore they all have= the > same spec. =20 > =20 > =20 >=20 > Krista Papac=20 > Iron Mountain Digital > 5530 Bandini Blvd > Bell, CA 90201 US > Home Office: +1.714.846.8780 > Mobile: +1.714.865.7655 > Fax: +1.323.443.3573 > krista.papac@ironmountain.com > =20 > =B3Software Escrow for Dummies=B2 - order your complimentary copy today a= t > > www.ironmountain.com/escrowfordummies > > =20 > New Gartner Report: Successful Software Escrow Requires Planning and > Negotiation > Gartner advises: =B3It is also important that the licensee continue to tr= ack the > software vendor=B9s financials and viability annually, because any signs = of > financial problems would justify the cost of verification services.=B2 Co= ntinue > reading the full report at: > http://www.gartner.com/technology/media-products/reprints/ironmountain/17= 0569. > html=20 > .html>=20 > =20 >=20 >=20 > From: Francisco Arias [mailto:francisco.arias@icann.org] > Sent: Wednesday, April 21, 2010 9:26 PM > To: Papac, Krista; David Conrad; Hollenbeck, Scott > Cc: ire@ietf.org > Subject: Re: [ire] Prodding by one of the chairs > =20 > Currently each gTLD has its own data escrow format, for example, there ar= e > ones that use colon separated data, there are others that use XML and oth= ers > that use SQL dumps. JP also uses XML. >=20 > Even those that use XML, that are the majority, do not necessarily have t= he > same spec. >=20 > __=20 > Francisco >=20 >=20 >=20 > On 4/21/10 8:58 PM, "Krista Papac" wrote: > I'm not sure what is meant by "multiple escrow implementations". Escrow,= for > the most part, is fairly consistent across Registries and is exactly the = same > for all depositing Registrars. I don't see why this consistency can't > continue into the future. >=20 > Krista Papac > Iron Mountain Digital > 5530 Bandini Blvd > Bell, CA 90201 US > Home Office: +1.714.846.8780 > Mobile: +1.714.865.7655 > Fax: +1.323.443.3573 > krista.papac@ironmountain.com >=20 > "Software Escrow for Dummies" - order your complimentary copy today at > www.ironmountain.com/escrowfordummies >=20 > New Gartner Report: Successful Software Escrow Requires Planning and > Negotiation > Gartner advises: "It is also important that the licensee continue to trac= k the > software vendor's financials and viability annually, because any signs of > financial problems would justify the cost of verification services." Cont= inue > reading the full report at: > http://www.gartner.com/technology/media-products/reprints/ironmountain/17= 0569. > html >=20 > -----Original Message----- > From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On Behalf Of Dav= id > Conrad > Sent: Wednesday, April 21, 2010 9:22 AM > To: Hollenbeck, Scott > Cc: ire@ietf.org > Subject: Re: [ire] Prodding by one of the chairs >=20 > Scott, >=20 > On Apr 21, 2010, at 4:11 AM, Hollenbeck, Scott wrote: >> Primarily because there are working escrow implementations, such as the >> one developed to meet the requirements of the .COM agreement between >> VeriSign and ICANN*, already in place. >=20 > I think the issue is that there are multiple escrow implementations and t= hat > it would probably be nice to standardize as that would likely facilitate = a > bunch of good things. >=20 > Regards, > -drc > Speaking personally >=20 > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire > ----------------------------------------- > The information contained in this email message and its attachments > is intended only for the private and confidential use of the > recipient(s) named above, unless the sender expressly agrees > otherwise. > Transmission of email over the Internet is not a secure > communications medium. If you are requesting or have requested the > transmittal of personal data, as defined in applicable privacy laws > by means of email or in an attachment to email, you must select a > more secure alternate means of transmittal that supports your > obligations to protect such personal data. > If the reader of this message is not the intended recipient and/or > you have received this email in error, you must take no action > based on the information in this email and you are hereby notified > that any dissemination, misuse or copying or disclosure of this > communication is strictly prohibited. If you have received this > communication in error, please notify us immediately by email and > delete the original message. > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire >=20 >=20 > The information contained in this email message and its attachments is > intended only for the private and confidential use of the recipient(s) na= med > above, unless the sender expressly agrees otherwise. Transmission of emai= l > over the Internet is not a secure communications medium. If you are reque= sting > or have requested the transmittal of personal data, as defined in applica= ble > privacy laws by means of email or in an attachment to email, you must sel= ect a > more secure alternate means of transmittal that supports your obligations= to > protect such personal data. If the reader of this message is not the inte= nded > recipient and/or you have received this email in error, you must take no > action based on the information in this email and you are hereby notified= that > any dissemination, misuse or copying or disclosure of this communication = is > strictly prohibited. If you have received this communication in error, pl= ease > notify us immediately by email and delete the original message. >=20 From shollenbeck@verisign.com Thu Apr 22 04:36:46 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55DE63A68A9 for ; Thu, 22 Apr 2010 04:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.041 X-Spam-Level: X-Spam-Status: No, score=-6.041 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJMpqYWgnUYR for ; Thu, 22 Apr 2010 04:36:45 -0700 (PDT) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id 7670A3A6840 for ; Thu, 22 Apr 2010 04:36:45 -0700 (PDT) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o3MBEo9t028158; Thu, 22 Apr 2010 07:14:50 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Apr 2010 07:36:34 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Apr 2010 07:36:31 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF070331E435@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <82F87B34-C652-44BB-95CE-0C25659AB3F3@virtualized.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ire] Prodding by one of the chairs Thread-Index: Acrh1FusrH7Woa4lQfuFktp1zqTMvQAOWS4g References: <046F43A8D79C794FA4733814869CDF070331E333@dul1wnexmb01.vcorp.ad.vrsn.com><046F43A8D79C794FA4733814869CDF070331E397@dul1wnexmb01.vcorp.ad.vrsn.com><6946BF6E-50C3-4C89-95D6-FB4EC7466C5F@virtualized.org><1CB60B47EE74294DAC9EE08837E617E29D8E2C64CE@NUMEVP11.na.imtn.com><776B9871-38FF-4226-BC71-A8643C6E1D89@virtualized.org><1CB60B47EE74294DAC9EE08837E617E29D8E2C64CF@NUMEVP11.na.imtn.com> <82F87B34-C652-44BB-95CE-0C25659AB3F3@virtualized.org> From: "Hollenbeck, Scott" To: "David Conrad" X-OriginalArrivalTime: 22 Apr 2010 11:36:34.0165 (UTC) FILETIME=[0F8BBA50:01CAE210] Cc: ire@ietf.org Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 11:36:46 -0000 > -----Original Message----- > From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On=20 > Behalf Of David Conrad > Sent: Thursday, April 22, 2010 12:29 AM > To: Papac, Krista > Cc: ire@ietf.org > Subject: Re: [ire] Prodding by one of the chairs >=20 > Krista, >=20 > On Apr 21, 2010, at 9:13 PM, Papac, Krista wrote: > > there currently aren't specs for these situations but that=20 > shouldn't prevent us from creating a spec for where=20 > consistency is required for these additional data fields. =20 >=20 > I believe that's the point of the working group. This touches on the thing that I still don't understand: there are existing specifications for registry (multiple formats) and registrar (standard format) data escrow that were developed outside the IETF using some process. Some people feel that there's a need for a standard registry escrow data format specification. Why is the process that was used to develop the registrar specification inadequate? What were the specific issues with that process that makes the IETF process more suitable to do the work? In other words, I'd really like to ask the people who think that there's IETF work here to please support their position. For whatever it's worth, I do believe there's value in having a standard format for escrow of registry technical data. I'm less convinced of the value when we start talking about business and/or financial data, but we can debate that later. Scott From myoung@ca.afilias.info Thu Apr 22 05:24:08 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65743A6A62 for ; Thu, 22 Apr 2010 05:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.665 X-Spam-Level: X-Spam-Status: No, score=-3.665 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oi10cV40ILfX for ; Thu, 22 Apr 2010 05:24:07 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 420E03A6AAD for ; Thu, 22 Apr 2010 05:23:08 -0700 (PDT) From: "Michael Young" To: "'Hollenbeck, Scott'" , "'David Conrad'" References: <046F43A8D79C794FA4733814869CDF070331E333@dul1wnexmb01.vcorp.ad.vrsn.com><046F43A8D79C794FA4733814869CDF070331E397@dul1wnexmb01.vcorp.ad.vrsn.com><6946BF6E-50C3-4C89-95D6-FB4EC7466C5F@virtualized.org><1CB60B47EE74294DAC9EE08837E617E29D8E2C64CE@NUMEVP11.na.imtn.com><776B9871-38FF-4226-BC71-A8643C6E1D89@virtualized.org><1CB60B47EE74294DAC9EE08837E617E29D8E2C64CF@NUMEVP11.na.imtn.com> <82F87B34-C652-44BB-95CE-0C25659AB3F3@virtualized.org> <046F43A8D79C794FA4733814869CDF070331E435@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <046F43A8D79C794FA4733814869CDF070331E435@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Thu, 22 Apr 2010 08:23:13 -0400 Message-ID: <001501cae216$94901970$bdb04c50$@afilias.info> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrh1FusrH7Woa4lQfuFktp1zqTMvQAOWS4gAAG54nA= Content-Language: en-us X-Authenticated: True Cc: ire@ietf.org Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 12:24:08 -0000 Scott my take on it is that there is good precedent for the IETF to provide the forum for the development of related technical specifications given past registry and DNS endeavors. ICANN is certainly not a body that was created with the idea of handling the development of said specifications. EPP and DNS related RFCs are directly referred to within all ICANN registry contracts. Some of the very same people that formed the IETF also helped formed ICANN, I think it was pretty clear they expected technical specifications to handled by technical people in the IETF forum and not by policy folks in the ICANN forum. Escrow was one of the after-thoughts that I believe slipped through the cracks, it should have been fully developed in the IETF in the first place, by implementers that know what the consequences of what they are specifying. The IETF forum also allows neutral participation by ccTLD registry operators and registrars as well the g/sTLDs under operational contracts with ICANN. As far as the general work goes, it meets the criteria as far as I can see. It's clearly internet related, it's a technical specification that a known internet community can benefit from being standardized (that we have interested volunteers from) and it's a project for which we can achieve a well defined scope (although like you I think this is about registry data, not business or financial). Does that answer the question? Thanks Michael Young -----Original Message----- From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: Thursday, April 22, 2010 7:37 AM To: David Conrad Cc: ire@ietf.org Subject: Re: [ire] Prodding by one of the chairs > -----Original Message----- > From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On > Behalf Of David Conrad > Sent: Thursday, April 22, 2010 12:29 AM > To: Papac, Krista > Cc: ire@ietf.org > Subject: Re: [ire] Prodding by one of the chairs > > Krista, > > On Apr 21, 2010, at 9:13 PM, Papac, Krista wrote: > > there currently aren't specs for these situations but that > shouldn't prevent us from creating a spec for where > consistency is required for these additional data fields. > > I believe that's the point of the working group. This touches on the thing that I still don't understand: there are existing specifications for registry (multiple formats) and registrar (standard format) data escrow that were developed outside the IETF using some process. Some people feel that there's a need for a standard registry escrow data format specification. Why is the process that was used to develop the registrar specification inadequate? What were the specific issues with that process that makes the IETF process more suitable to do the work? In other words, I'd really like to ask the people who think that there's IETF work here to please support their position. For whatever it's worth, I do believe there's value in having a standard format for escrow of registry technical data. I'm less convinced of the value when we start talking about business and/or financial data, but we can debate that later. Scott _______________________________________________ ire mailing list ire@ietf.org https://www.ietf.org/mailman/listinfo/ire From shollenbeck@verisign.com Thu Apr 22 05:36:40 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95CFA3A6A67 for ; Thu, 22 Apr 2010 05:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.181 X-Spam-Level: X-Spam-Status: No, score=-6.181 tagged_above=-999 required=5 tests=[AWL=0.419, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgjlqRFTNsvd for ; Thu, 22 Apr 2010 05:36:39 -0700 (PDT) Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by core3.amsl.com (Postfix) with ESMTP id 05E5E3A68C6 for ; Thu, 22 Apr 2010 05:36:23 -0700 (PDT) Received: from dul1wnexcn03.vcorp.ad.vrsn.com (dul1wnexcn03.vcorp.ad.vrsn.com [10.170.12.113]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id o3MCSNvv003961; Thu, 22 Apr 2010 08:28:23 -0400 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Apr 2010 08:35:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Apr 2010 08:35:51 -0400 Message-ID: <046F43A8D79C794FA4733814869CDF070331E43A@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <001501cae216$94901970$bdb04c50$@afilias.info> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [ire] Prodding by one of the chairs Thread-Index: Acrh1FusrH7Woa4lQfuFktp1zqTMvQAOWS4gAAG54nAAAIYa4A== References: <046F43A8D79C794FA4733814869CDF070331E333@dul1wnexmb01.vcorp.ad.vrsn.com><046F43A8D79C794FA4733814869CDF070331E397@dul1wnexmb01.vcorp.ad.vrsn.com><6946BF6E-50C3-4C89-95D6-FB4EC7466C5F@virtualized.org><1CB60B47EE74294DAC9EE08837E617E29D8E2C64CE@NUMEVP11.na.imtn.com><776B9871-38FF-4226-BC71-A8643C6E1D89@virtualized.org><1CB60B47EE74294DAC9EE08837E617E29D8E2C64CF@NUMEVP11.na.imtn.com> <82F87B34-C652-44BB-95CE-0C25659AB3F3@virtualized.org> <046F43A8D79C794FA4733814869CDF070331E435@dul1wnexmb01.vcorp.ad.vrsn.com> <001501cae216$94901970$bdb04c50$@afilias.info> From: "Hollenbeck, Scott" To: "Michael Young" X-OriginalArrivalTime: 22 Apr 2010 12:35:52.0958 (UTC) FILETIME=[58C071E0:01CAE218] Cc: ire@ietf.org Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 12:36:40 -0000 > -----Original Message----- > From: Michael Young [mailto:myoung@ca.afilias.info]=20 > Sent: Thursday, April 22, 2010 8:23 AM > To: Hollenbeck, Scott; 'David Conrad' > Cc: ire@ietf.org > Subject: RE: [ire] Prodding by one of the chairs >=20 > Scott my take on it is that there is good precedent for the=20 > IETF to provide the forum for the development of related=20 > technical specifications given past registry and DNS=20 > endeavors. ICANN is certainly not a body that was created=20 > with the idea of handling the development of said=20 > specifications. EPP and DNS related RFCs are directly=20 > referred to within all ICANN registry contracts. Some of the=20 > very same people that formed the IETF also helped formed=20 > ICANN, I think it was pretty clear they expected technical=20 > specifications to handled by technical people in the IETF=20 > forum and not by policy folks in the ICANN forum. >=20 > Escrow was one of the after-thoughts that I believe slipped=20 > through the cracks, it should have been fully developed in=20 > the IETF in the first place, by implementers that know what=20 > the consequences of what they are specifying. > The IETF forum also allows neutral participation by ccTLD=20 > registry operators and registrars as well the g/sTLDs under=20 > operational contracts with ICANN. >=20 > As far as the general work goes, it meets the criteria as far=20 > as I can see. > It's clearly internet related, it's a technical specification=20 > that a known internet community can benefit from being=20 > standardized (that we have interested volunteers from) and=20 > it's a project for which we can achieve a well defined scope=20 > (although like you I think this is about registry data, not=20 > business or financial). >=20 > Does that answer the question? Incompletely - while you described the benefits of the work being done in the IETF (assuming that the scope is narrowed to technical data I understand those benefits), you didn't describe any issues with the process that was used to develop the registrar specification. Did you take part in that effort? Original message included below for context... Scott > -----Original Message----- > From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] > Sent: Thursday, April 22, 2010 7:37 AM > To: David Conrad > Cc: ire@ietf.org > Subject: Re: [ire] Prodding by one of the chairs >=20 > > -----Original Message----- > > From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On=20 > Behalf Of=20 > > David Conrad > > Sent: Thursday, April 22, 2010 12:29 AM > > To: Papac, Krista > > Cc: ire@ietf.org > > Subject: Re: [ire] Prodding by one of the chairs > >=20 > > Krista, > >=20 > > On Apr 21, 2010, at 9:13 PM, Papac, Krista wrote: > > > there currently aren't specs for these situations but that > > shouldn't prevent us from creating a spec for where consistency is=20 > > required for these additional data fields. > >=20 > > I believe that's the point of the working group. >=20 > This touches on the thing that I still don't understand: =20 > there are existing specifications for registry (multiple=20 > formats) and registrar (standard format) data escrow that=20 > were developed outside the IETF using some process. Some=20 > people feel that there's a need for a standard registry=20 > escrow data format specification. Why is the process that=20 > was used to develop the registrar specification inadequate? =20 > What were the specific issues with that process that makes=20 > the IETF process more suitable to do the work? >=20 > In other words, I'd really like to ask the people who think=20 > that there's IETF work here to please support their position.=20 > For whatever it's worth, I do believe there's value in=20 > having a standard format for escrow of registry technical=20 > data. I'm less convinced of the value when we start talking=20 > about business and/or financial data, but we can debate that later. >=20 > Scott > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire >=20 >=20 From myoung@ca.afilias.info Thu Apr 22 05:42:29 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 280CF3A6807 for ; Thu, 22 Apr 2010 05:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KAxwjFAC8+1o for ; Thu, 22 Apr 2010 05:42:27 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 12DE63A691C for ; Thu, 22 Apr 2010 05:42:25 -0700 (PDT) From: "Michael Young" To: "'Hollenbeck, Scott'" References: <046F43A8D79C794FA4733814869CDF070331E333@dul1wnexmb01.vcorp.ad.vrsn.com><046F43A8D79C794FA4733814869CDF070331E397@dul1wnexmb01.vcorp.ad.vrsn.com><6946BF6E-50C3-4C89-95D6-FB4EC7466C5F@virtualized.org><1CB60B47EE74294DAC9EE08837E617E29D8E2C64CE@NUMEVP11.na.imtn.com><776B9871-38FF-4226-BC71-A8643C6E1D89@virtualized.org><1CB60B47EE74294DAC9EE08837E617E29D8E2C64CF@NUMEVP11.na.imtn.com> <82F87B34-C652-44BB-95CE-0C25659AB3F3@virtualized.org> <046F43A8D79C794FA4733814869CDF070331E435@dul1wnexmb01.vcorp.ad.vrsn.com> <001501cae216$94901970$bdb04c50$@afilias.info> <046F43A8D79C794FA4733814869CDF070331E43A@dul1wnexmb01.vcorp.ad.vrsn.com> In-Reply-To: <046F43A8D79C794FA4733814869CDF070331E43A@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Thu, 22 Apr 2010 08:42:32 -0400 Message-ID: <001601cae219$46ed7f70$d4c87e50$@afilias.info> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrh1FusrH7Woa4lQfuFktp1zqTMvQAOWS4gAAG54nAAAIYa4AAAkeHw Content-Language: en-us X-Authenticated: True Cc: ire@ietf.org Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 12:42:29 -0000 I can only comment as far as I have, sorry, as I did not work on the registrar specification. Hopefully others can chime in on that piece. Michael -----Original Message----- From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] Sent: Thursday, April 22, 2010 8:36 AM To: Michael Young Cc: ire@ietf.org Subject: RE: [ire] Prodding by one of the chairs > -----Original Message----- > From: Michael Young [mailto:myoung@ca.afilias.info] > Sent: Thursday, April 22, 2010 8:23 AM > To: Hollenbeck, Scott; 'David Conrad' > Cc: ire@ietf.org > Subject: RE: [ire] Prodding by one of the chairs > > Scott my take on it is that there is good precedent for the > IETF to provide the forum for the development of related > technical specifications given past registry and DNS > endeavors. ICANN is certainly not a body that was created > with the idea of handling the development of said > specifications. EPP and DNS related RFCs are directly > referred to within all ICANN registry contracts. Some of the > very same people that formed the IETF also helped formed > ICANN, I think it was pretty clear they expected technical > specifications to handled by technical people in the IETF > forum and not by policy folks in the ICANN forum. > > Escrow was one of the after-thoughts that I believe slipped > through the cracks, it should have been fully developed in > the IETF in the first place, by implementers that know what > the consequences of what they are specifying. > The IETF forum also allows neutral participation by ccTLD > registry operators and registrars as well the g/sTLDs under > operational contracts with ICANN. > > As far as the general work goes, it meets the criteria as far > as I can see. > It's clearly internet related, it's a technical specification > that a known internet community can benefit from being > standardized (that we have interested volunteers from) and > it's a project for which we can achieve a well defined scope > (although like you I think this is about registry data, not > business or financial). > > Does that answer the question? Incompletely - while you described the benefits of the work being done in the IETF (assuming that the scope is narrowed to technical data I understand those benefits), you didn't describe any issues with the process that was used to develop the registrar specification. Did you take part in that effort? Original message included below for context... Scott > -----Original Message----- > From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] > Sent: Thursday, April 22, 2010 7:37 AM > To: David Conrad > Cc: ire@ietf.org > Subject: Re: [ire] Prodding by one of the chairs > > > -----Original Message----- > > From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On > Behalf Of > > David Conrad > > Sent: Thursday, April 22, 2010 12:29 AM > > To: Papac, Krista > > Cc: ire@ietf.org > > Subject: Re: [ire] Prodding by one of the chairs > > > > Krista, > > > > On Apr 21, 2010, at 9:13 PM, Papac, Krista wrote: > > > there currently aren't specs for these situations but that > > shouldn't prevent us from creating a spec for where consistency is > > required for these additional data fields. > > > > I believe that's the point of the working group. > > This touches on the thing that I still don't understand: > there are existing specifications for registry (multiple > formats) and registrar (standard format) data escrow that > were developed outside the IETF using some process. Some > people feel that there's a need for a standard registry > escrow data format specification. Why is the process that > was used to develop the registrar specification inadequate? > What were the specific issues with that process that makes > the IETF process more suitable to do the work? > > In other words, I'd really like to ask the people who think > that there's IETF work here to please support their position. > For whatever it's worth, I do believe there's value in > having a standard format for escrow of registry technical > data. I'm less convinced of the value when we start talking > about business and/or financial data, but we can debate that later. > > Scott > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire > > From yaojk@cnnic.cn Thu Apr 22 06:09:26 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 483993A6909 for ; Thu, 22 Apr 2010 06:09:26 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 2.179 X-Spam-Level: ** X-Spam-Status: No, score=2.179 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_20=-0.74, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSM5JTn1hpRS for ; Thu, 22 Apr 2010 06:09:25 -0700 (PDT) Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id EFBB928C0F2 for ; Thu, 22 Apr 2010 06:09:22 -0700 (PDT) Received: (eyou send program); Thu, 22 Apr 2010 21:09:13 +0800 Message-ID: <471941753.29759@cnnic.cn> X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn Received: from unknown (HELO abc) (127.0.0.1) by 127.0.0.1 with SMTP; Thu, 22 Apr 2010 21:09:13 +0800 Message-ID: <62961F1A47DB476CB69EDBAB90D702C4@abc> From: "Yao Jiankang" To: "Hollenbeck, Scott" , "David Conrad" References: <046F43A8D79C794FA4733814869CDF070331E333@dul1wnexmb01.vcorp.ad.vrsn.com><046F43A8D79C794FA4733814869CDF070331E397@dul1wnexmb01.vcorp.ad.vrsn.com><6946BF6E-50C3-4C89-95D6-FB4EC7466C5F@virtualized.org><1CB60B47EE74294DAC9EE08837E617E29D8E2C64CE@NUMEVP11.na.imtn.com><776B9871-38FF-4226-BC71-A8643C6E1D89@virtualized.org><1CB60B47EE74294DAC9EE08837E617E29D8E2C64CF@NUMEVP11.na.imtn.com><82F87B34-C652-44BB-95CE-0C25659AB3F3@virtualized.org> <046F43A8D79C794FA4733814869CDF070331E435@dul1wnexmb01.vcorp.ad.vrsn.com> Date: Thu, 22 Apr 2010 21:09:10 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 Cc: ire@ietf.org Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 13:09:26 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkhvbGxlbmJlY2ssIFNjb3R0 IiA8c2hvbGxlbmJlY2tAdmVyaXNpZ24uY29tPg0KVG86ICJEYXZpZCBDb25yYWQiIDxkcmNAdmly dHVhbGl6ZWQub3JnPg0KQ2M6IDxpcmVAaWV0Zi5vcmc+DQpTZW50OiBUaHVyc2RheSwgQXByaWwg MjIsIDIwMTAgNzozNiBQTQ0KU3ViamVjdDogUmU6IFtpcmVdIFByb2RkaW5nIGJ5IG9uZSBvZiB0 aGUgY2hhaXJzDQoNCg0KDQoNCj5JbiBvdGhlciB3b3JkcywgSSdkIHJlYWxseSBsaWtlIHRvIGFz ayB0aGUgcGVvcGxlIHdobyB0aGluayB0aGF0IHRoZXJlJ3MNCj5JRVRGIHdvcmsgaGVyZSB0byBw bGVhc2Ugc3VwcG9ydCB0aGVpciBwb3NpdGlvbi4gDQp5ZXMsIEkgdGhpbmsgdGhhdCB0aGVyZSBp cyBzb21lIHZhbHVlIHRvIGJlIGRvbmUgaW4gSUVURi4NCnRoZSB1bmlmb3JtIG9mIGVzY3JvdyBp cyBnb29kIGZvciBhbGwga2luZHMgb2YgZG9tYWluIHJlbGF0ZWQgb3JnYW5pemF0aW9uIGFuZCBz ZXJ2aWNlcy4NCg0KPiBGb3Igd2hhdGV2ZXIgaXQncw0KPndvcnRoLCBJIGRvIGJlbGlldmUgdGhl cmUncyB2YWx1ZSBpbiBoYXZpbmcgYSBzdGFuZGFyZCBmb3JtYXQgZm9yIGVzY3Jvdw0KPm9mIHJl Z2lzdHJ5IHRlY2huaWNhbCBkYXRhLg0KDQorMQ0K From prvs=1721de7dc6=krista.papac@ironmountain.com Thu Apr 22 07:56:36 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C92A3A6BC4 for ; Thu, 22 Apr 2010 07:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.434, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Oti30wATwW8 for ; Thu, 22 Apr 2010 07:56:34 -0700 (PDT) Received: from kcsmtp01.ironmountain.com (kcsmtp01.ironmountain.com [216.229.158.20]) by core3.amsl.com (Postfix) with ESMTP id CA07D3A6833 for ; Thu, 22 Apr 2010 07:53:57 -0700 (PDT) Received: from ([10.130.80.70]) by kcsmtp01.ironmountain.com with ESMTP with TLS id 6GMF5H1.105913986; Thu, 22 Apr 2010 09:53:23 -0500 Received: from NUMEVP11.na.imtn.com ([169.254.2.218]) by NUMEHTP03.na.imtn.com ([fe80::c85a:86e5:44d7:3d6d%10]) with mapi; Thu, 22 Apr 2010 10:53:23 -0400 From: "Papac, Krista" To: Michael Young , "'Hollenbeck, Scott'" Date: Thu, 22 Apr 2010 10:53:21 -0400 Thread-Topic: [ire] Prodding by one of the chairs Thread-Index: Acrh1FusrH7Woa4lQfuFktp1zqTMvQAOWS4gAAG54nAAAIYa4AAAkeHwAAR/elA= Message-ID: <1CB60B47EE74294DAC9EE08837E617E29D8E2C6655@NUMEVP11.na.imtn.com> References: <046F43A8D79C794FA4733814869CDF070331E333@dul1wnexmb01.vcorp.ad.vrsn.com><046F43A8D79C794FA4733814869CDF070331E397@dul1wnexmb01.vcorp.ad.vrsn.com><6946BF6E-50C3-4C89-95D6-FB4EC7466C5F@virtualized.org><1CB60B47EE74294DAC9EE08837E617E29D8E2C64CE@NUMEVP11.na.imtn.com><776B9871-38FF-4226-BC71-A8643C6E1D89@virtualized.org><1CB60B47EE74294DAC9EE08837E617E29D8E2C64CF@NUMEVP11.na.imtn.com> <82F87B34-C652-44BB-95CE-0C25659AB3F3@virtualized.org> <046F43A8D79C794FA4733814869CDF070331E435@dul1wnexmb01.vcorp.ad.vrsn.com> <001501cae216$94901970$bdb04c50$@afilias.info> <046F43A8D79C794FA4733814869CDF070331E43A@dul1wnexmb01.vcorp.ad.vrsn.com> <001601cae219$46ed7f70$d4c87e50$@afilias.info> In-Reply-To: <001601cae219$46ed7f70$d4c87e50$@afilias.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: "ire@ietf.org" Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 14:56:36 -0000 I am not familiar with the process that was used to develop the registrar s= pec, but what I do know is the spec was developed by the Registrar Liaison = office=2E Mike Zupke was responsible for executing and delivering on all a= spects Registrar Data Escrow=2E I "believe" he wrote the spec, but assume = he consulted with others in the ICANN organization=2E =0D=0A=0D=0AMaybe Fr= ancisco can look further into this???=0D=0A=0D=0AKrista Papac =0D=0AIron Mo= untain Digital =0D=0A5530 Bandini Blvd =0D=0ABell, CA 90201 US =0D=0AHome= Office: +1=2E714=2E846=2E8780 =0D=0AMobile: +1=2E714=2E865=2E7655 =0D=0AFa= x: +1=2E323=2E443=2E3573 =0D=0Akrista=2Epapac@ironmountain=2Ecom =0D=0A =0D= =0A"Software Escrow for Dummies" - order your complimentary copy today at w= ww=2Eironmountain=2Ecom/escrowfordummies=0D=0A =0D=0ANew Gartner Report: Su= ccessful Software Escrow Requires Planning and Negotiation=0D=0AGartner adv= ises: "It is also important that the licensee continue to track the softwar= e vendor's financials and viability annually, because any signs of financia= l problems would justify the cost of verification services=2E" Continue rea= ding the full report at: http://www=2Egartner=2Ecom/technology/media-produc= ts/reprints/ironmountain/170569=2Ehtml=0D=0A=0D=0A-----Original Message----= -=0D=0AFrom: ire-bounces@ietf=2Eorg [mailto:ire-bounces@ietf=2Eorg] On Beha= lf Of Michael Young=0D=0ASent: Thursday, April 22, 2010 5:43 AM=0D=0ATo: 'H= ollenbeck, Scott'=0D=0ACc: ire@ietf=2Eorg=0D=0ASubject: Re: [ire] Prodding = by one of the chairs=0D=0A=0D=0AI can only comment as far as I have, sorry,= as I did not work on the=0D=0Aregistrar specification=2E Hopefully others = can chime in on that piece=2E=0D=0A=0D=0AMichael=0D=0A=0D=0A-----Original M= essage-----=0D=0AFrom: Hollenbeck, Scott [mailto:shollenbeck@verisign=2Ecom= ] =0D=0ASent: Thursday, April 22, 2010 8:36 AM=0D=0ATo: Michael Young=0D=0A= Cc: ire@ietf=2Eorg=0D=0ASubject: RE: [ire] Prodding by one of the chairs=0D= =0A=0D=0A> -----Original Message-----=0D=0A> From: Michael Young [mailto:my= oung@ca=2Eafilias=2Einfo] =0D=0A> Sent: Thursday, April 22, 2010 8:23 AM=0D= =0A> To: Hollenbeck, Scott; 'David Conrad'=0D=0A> Cc: ire@ietf=2Eorg=0D=0A>= Subject: RE: [ire] Prodding by one of the chairs=0D=0A> =0D=0A> Scott my t= ake on it is that there is good precedent for the =0D=0A> IETF to provide t= he forum for the development of related =0D=0A> technical specifications gi= ven past registry and DNS =0D=0A> endeavors=2E ICANN is certainly not a bo= dy that was created =0D=0A> with the idea of handling the development of sa= id =0D=0A> specifications=2E EPP and DNS related RFCs are directly =0D=0A>= referred to within all ICANN registry contracts=2E Some of the =0D=0A> ve= ry same people that formed the IETF also helped formed =0D=0A> ICANN, I thi= nk it was pretty clear they expected technical =0D=0A> specifications to ha= ndled by technical people in the IETF =0D=0A> forum and not by policy folks= in the ICANN forum=2E=0D=0A> =0D=0A> Escrow was one of the after-thoughts = that I believe slipped =0D=0A> through the cracks, it should have been full= y developed in =0D=0A> the IETF in the first place, by implementers that kn= ow what =0D=0A> the consequences of what they are specifying=2E=0D=0A> The = IETF forum also allows neutral participation by ccTLD =0D=0A> registry oper= ators and registrars as well the g/sTLDs under =0D=0A> operational contract= s with ICANN=2E=0D=0A> =0D=0A> As far as the general work goes, it meets th= e criteria as far =0D=0A> as I can see=2E=0D=0A> It's clearly internet rela= ted, it's a technical specification =0D=0A> that a known internet community= can benefit from being =0D=0A> standardized (that we have interested volun= teers from) and =0D=0A> it's a project for which we can achieve a well defi= ned scope =0D=0A> (although like you I think this is about registry data, n= ot =0D=0A> business or financial)=2E=0D=0A> =0D=0A> Does that answer the qu= estion?=0D=0A=0D=0AIncompletely - while you described the benefits of the w= ork being done=0D=0Ain the IETF (assuming that the scope is narrowed to tec= hnical data I=0D=0Aunderstand those benefits), you didn't describe any issu= es with the=0D=0Aprocess that was used to develop the registrar specificati= on=2E Did you=0D=0Atake part in that effort?=0D=0A=0D=0AOriginal message i= ncluded below for context=2E=2E=2E=0D=0A=0D=0AScott=0D=0A=0D=0A> -----Origi= nal Message-----=0D=0A> From: Hollenbeck, Scott [mailto:shollenbeck@verisig= n=2Ecom]=0D=0A> Sent: Thursday, April 22, 2010 7:37 AM=0D=0A> To: David Con= rad=0D=0A> Cc: ire@ietf=2Eorg=0D=0A> Subject: Re: [ire] Prodding by one of = the chairs=0D=0A> =0D=0A> > -----Original Message-----=0D=0A> > From: ire-b= ounces@ietf=2Eorg [mailto:ire-bounces@ietf=2Eorg] On =0D=0A> Behalf Of =0D= =0A> > David Conrad=0D=0A> > Sent: Thursday, April 22, 2010 12:29 AM=0D=0A>= > To: Papac, Krista=0D=0A> > Cc: ire@ietf=2Eorg=0D=0A> > Subject: Re: [ire= ] Prodding by one of the chairs=0D=0A> > =0D=0A> > Krista,=0D=0A> > =0D=0A>= > On Apr 21, 2010, at 9:13 PM, Papac, Krista wrote:=0D=0A> > > there curre= ntly aren't specs for these situations but that=0D=0A> > shouldn't prevent = us from creating a spec for where consistency is =0D=0A> > required for the= se additional data fields=2E=0D=0A> > =0D=0A> > I believe that's the point = of the working group=2E=0D=0A> =0D=0A> This touches on the thing that I sti= ll don't understand: =0D=0A> there are existing specifications for registr= y (multiple =0D=0A> formats) and registrar (standard format) data escrow th= at =0D=0A> were developed outside the IETF using some process=2E Some =0D= =0A> people feel that there's a need for a standard registry =0D=0A> escrow= data format specification=2E Why is the process that =0D=0A> was used to = develop the registrar specification inadequate? =0D=0A> What were the spec= ific issues with that process that makes =0D=0A> the IETF process more suit= able to do the work?=0D=0A> =0D=0A> In other words, I'd really like to ask = the people who think =0D=0A> that there's IETF work here to please support = their position=2E =0D=0A> For whatever it's worth, I do believe there's va= lue in =0D=0A> having a standard format for escrow of registry technical = =0D=0A> data=2E I'm less convinced of the value when we start talking =0D= =0A> about business and/or financial data, but we can debate that later=2E= =0D=0A> =0D=0A> Scott=0D=0A> ______________________________________________= _=0D=0A> ire mailing list=0D=0A> ire@ietf=2Eorg=0D=0A> https://www=2Eietf= =2Eorg/mailman/listinfo/ire=0D=0A> =0D=0A> =0D=0A=0D=0A____________________= ___________________________=0D=0Aire mailing list=0D=0Aire@ietf=2Eorg=0D=0A= https://www=2Eietf=2Eorg/mailman/listinfo/ire=0D=0A------------------------= -----------------=0D=0AThe information contained in this email message and = its attachments=0Ais intended only for the private and confidential use of = the=0Arecipient(s) named above, unless the sender expressly agrees=0Aotherw= ise=2E=0D=0ATransmission of email over the Internet is not a secure=0Acommu= nications medium=2E If you are requesting or have requested the=0Atransmitt= al of personal data, as defined in applicable privacy laws=0Aby means of em= ail or in an attachment to email, you must select a=0Amore secure alternate= means of transmittal that supports your=0Aobligations to protect such pers= onal data=2E =0D=0AIf the reader of this message is not the intended recipi= ent and/or=0Ayou have received this email in error, you must take no action= =0Abased on the information in this email and you are hereby notified=0Atha= t any dissemination, misuse or copying or disclosure of this=0Acommunicatio= n is strictly prohibited=2E If you have received this=0Acommunication in er= ror, please notify us immediately by email and=0Adelete the original messag= e=2E From drc@virtualized.org Thu Apr 22 09:13:10 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3363A6BE9 for ; Thu, 22 Apr 2010 09:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oV4mXfWssAya for ; Thu, 22 Apr 2010 09:13:08 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id BE3C828C132 for ; Thu, 22 Apr 2010 09:12:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id 8DBECBBA84E; Thu, 22 Apr 2010 09:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJB+DwQYjtCl; Thu, 22 Apr 2010 09:12:33 -0700 (PDT) Received: from [198.134.93.209] (unknown [198.134.93.209]) by virtualized.org (Postfix) with ESMTP id 9C1BCBBA840; Thu, 22 Apr 2010 09:12:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <1CB60B47EE74294DAC9EE08837E617E29D8E2C6655@NUMEVP11.na.imtn.com> Date: Thu, 22 Apr 2010 09:12:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <046F43A8D79C794FA4733814869CDF070331E333@dul1wnexmb01.vcorp.ad.vrsn.com><046F43A8D79C794FA4733814869CDF070331E397@dul1wnexmb01.vcorp.ad.vrsn.com><6946BF6E-50C3-4C89-95D6-FB4EC7466C5F@virtualized.org><1CB60B47EE74294DAC9EE08837E617E29D8E2C64CE@NUMEVP11.na.imtn.com><776B9871-38FF-4226-BC71-A8643C6E1D89@virtualized.org><1CB60B47EE74294DAC9EE08837E617E29D8E2C64CF@NUMEVP11.na.imtn.com> <82F87B34-C652-44BB-95CE-0C25659AB3F3@virtualized.org> <046F43A8D79C794FA4733814869CDF070331E435@dul1wnexmb01.vcorp.ad.vrsn.com> <001501cae216$94901970$bdb04c50$@afilias.info> <046F43A8D79C794FA4733814869CDF070331E43A@dul1wnexmb01.vcorp.ad.vrsn.com> <001601cae219$46ed7f70$d4c87e50$@afilias.info> <1CB60B47EE74294DAC9EE08837E617E29D8E2C6655@NUMEVP11.na.imtn.com> To: "Papac, Krista" X-Mailer: Apple Mail (2.1078) Cc: ire@ietf.org Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 16:13:11 -0000 Krista and Scott, I think the idea here is that a data escrow standard defined by a = neutral 3rd party like the IETF could be used by more folks than just = ICANN and the ICANN contracted parties. Further, I personally believe = folks who participate in the IETF (who may not show up in ICANN-related = forums) have expertise in the areas of data definition and use and that = could be quite helpful in providing a more generally useful = specification. Regards, -drc Speaking personally On Apr 22, 2010, at 7:53 AM, Papac, Krista wrote: > I am not familiar with the process that was used to develop the = registrar spec, but what I do know is the spec was developed by the = Registrar Liaison office. Mike Zupke was responsible for executing and = delivering on all aspects Registrar Data Escrow. I "believe" he wrote = the spec, but assume he consulted with others in the ICANN organization. = =20 >=20 > Maybe Francisco can look further into this??? >=20 > Krista Papac=20 > Iron Mountain Digital=20 > 5530 Bandini Blvd=20 > Bell, CA 90201 US=20 > Home Office: +1.714.846.8780=20 > Mobile: +1.714.865.7655=20 > Fax: +1.323.443.3573=20 > krista.papac@ironmountain.com=20 >=20 > "Software Escrow for Dummies" - order your complimentary copy today at = www.ironmountain.com/escrowfordummies >=20 > New Gartner Report: Successful Software Escrow Requires Planning and = Negotiation > Gartner advises: "It is also important that the licensee continue to = track the software vendor's financials and viability annually, because = any signs of financial problems would justify the cost of verification = services." Continue reading the full report at: = http://www.gartner.com/technology/media-products/reprints/ironmountain/170= 569.html >=20 > -----Original Message----- > From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On Behalf Of = Michael Young > Sent: Thursday, April 22, 2010 5:43 AM > To: 'Hollenbeck, Scott' > Cc: ire@ietf.org > Subject: Re: [ire] Prodding by one of the chairs >=20 > I can only comment as far as I have, sorry, as I did not work on the > registrar specification. Hopefully others can chime in on that piece. >=20 > Michael >=20 > -----Original Message----- > From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com]=20 > Sent: Thursday, April 22, 2010 8:36 AM > To: Michael Young > Cc: ire@ietf.org > Subject: RE: [ire] Prodding by one of the chairs >=20 >> -----Original Message----- >> From: Michael Young [mailto:myoung@ca.afilias.info]=20 >> Sent: Thursday, April 22, 2010 8:23 AM >> To: Hollenbeck, Scott; 'David Conrad' >> Cc: ire@ietf.org >> Subject: RE: [ire] Prodding by one of the chairs >>=20 >> Scott my take on it is that there is good precedent for the=20 >> IETF to provide the forum for the development of related=20 >> technical specifications given past registry and DNS=20 >> endeavors. ICANN is certainly not a body that was created=20 >> with the idea of handling the development of said=20 >> specifications. EPP and DNS related RFCs are directly=20 >> referred to within all ICANN registry contracts. Some of the=20 >> very same people that formed the IETF also helped formed=20 >> ICANN, I think it was pretty clear they expected technical=20 >> specifications to handled by technical people in the IETF=20 >> forum and not by policy folks in the ICANN forum. >>=20 >> Escrow was one of the after-thoughts that I believe slipped=20 >> through the cracks, it should have been fully developed in=20 >> the IETF in the first place, by implementers that know what=20 >> the consequences of what they are specifying. >> The IETF forum also allows neutral participation by ccTLD=20 >> registry operators and registrars as well the g/sTLDs under=20 >> operational contracts with ICANN. >>=20 >> As far as the general work goes, it meets the criteria as far=20 >> as I can see. >> It's clearly internet related, it's a technical specification=20 >> that a known internet community can benefit from being=20 >> standardized (that we have interested volunteers from) and=20 >> it's a project for which we can achieve a well defined scope=20 >> (although like you I think this is about registry data, not=20 >> business or financial). >>=20 >> Does that answer the question? >=20 > Incompletely - while you described the benefits of the work being done > in the IETF (assuming that the scope is narrowed to technical data I > understand those benefits), you didn't describe any issues with the > process that was used to develop the registrar specification. Did you > take part in that effort? >=20 > Original message included below for context... >=20 > Scott >=20 >> -----Original Message----- >> From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] >> Sent: Thursday, April 22, 2010 7:37 AM >> To: David Conrad >> Cc: ire@ietf.org >> Subject: Re: [ire] Prodding by one of the chairs >>=20 >>> -----Original Message----- >>> From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On=20 >> Behalf Of=20 >>> David Conrad >>> Sent: Thursday, April 22, 2010 12:29 AM >>> To: Papac, Krista >>> Cc: ire@ietf.org >>> Subject: Re: [ire] Prodding by one of the chairs >>>=20 >>> Krista, >>>=20 >>> On Apr 21, 2010, at 9:13 PM, Papac, Krista wrote: >>>> there currently aren't specs for these situations but that >>> shouldn't prevent us from creating a spec for where consistency is=20= >>> required for these additional data fields. >>>=20 >>> I believe that's the point of the working group. >>=20 >> This touches on the thing that I still don't understand: =20 >> there are existing specifications for registry (multiple=20 >> formats) and registrar (standard format) data escrow that=20 >> were developed outside the IETF using some process. Some=20 >> people feel that there's a need for a standard registry=20 >> escrow data format specification. Why is the process that=20 >> was used to develop the registrar specification inadequate? =20 >> What were the specific issues with that process that makes=20 >> the IETF process more suitable to do the work? >>=20 >> In other words, I'd really like to ask the people who think=20 >> that there's IETF work here to please support their position.=20 >> For whatever it's worth, I do believe there's value in=20 >> having a standard format for escrow of registry technical=20 >> data. I'm less convinced of the value when we start talking=20 >> about business and/or financial data, but we can debate that later. >>=20 >> Scott >> _______________________________________________ >> ire mailing list >> ire@ietf.org >> https://www.ietf.org/mailman/listinfo/ire >>=20 >>=20 >=20 > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire > ----------------------------------------- > The information contained in this email message and its attachments > is intended only for the private and confidential use of the > recipient(s) named above, unless the sender expressly agrees > otherwise. > Transmission of email over the Internet is not a secure > communications medium. If you are requesting or have requested the > transmittal of personal data, as defined in applicable privacy laws > by means of email or in an attachment to email, you must select a > more secure alternate means of transmittal that supports your > obligations to protect such personal data.=20 > If the reader of this message is not the intended recipient and/or > you have received this email in error, you must take no action > based on the information in this email and you are hereby notified > that any dissemination, misuse or copying or disclosure of this > communication is strictly prohibited. If you have received this > communication in error, please notify us immediately by email and > delete the original message. > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire >=20 From ajs@shinkuro.com Thu Apr 22 09:34:44 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0968028C12C for ; Thu, 22 Apr 2010 09:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.31 X-Spam-Level: X-Spam-Status: No, score=-0.31 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFEMYSaRpLmY for ; Thu, 22 Apr 2010 09:34:43 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 4275C3A6A0E for ; Thu, 22 Apr 2010 09:33:49 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id CB6781ECB400 for ; Thu, 22 Apr 2010 16:33:37 +0000 (UTC) Date: Thu, 22 Apr 2010 12:33:36 -0400 From: Andrew Sullivan To: ire@ietf.org Message-ID: <20100422163335.GG1362@shinkuro.com> References: <82F87B34-C652-44BB-95CE-0C25659AB3F3@virtualized.org> <046F43A8D79C794FA4733814869CDF070331E435@dul1wnexmb01.vcorp.ad.vrsn.com> <001501cae216$94901970$bdb04c50$@afilias.info> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001501cae216$94901970$bdb04c50$@afilias.info> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 16:34:44 -0000 Dear colleagues, I think I agree with Scott that the arguments in favour of a WG to undertake work in this area still seem underwhelming. I'm picking on Michael below because his message was a handy summary of certain arguments that I think need strengthening before there's a good argument for a WG (and because I know he can take it ;-) On Thu, Apr 22, 2010 at 08:23:13AM -0400, Michael Young wrote: > with the idea of handling the development of said specifications. EPP and > DNS related RFCs are directly referred to within all ICANN registry > contracts. We had a bar BOF at Anaheim in which people were arguing that a number of different, incompatible extensions have emerged under EPP. One way to interpret that state of affairs is that the IETF ought to undertake to unify the specifications. But _another_ way to look at the evidence is that EPP worked: it's extensible, and people have added a lot of extensions because they had different local needs. In the same way, the multiplicity of escrow formats could reasonably be interpreted as an indication that different agreements required different responses, and therefore the escrow rules are different. Even if one didn't think that the different formats were really necessary, there's the additional matter of cost. It will not be free for people conforming to a current agreement to modify their systems to support a new format. What is the incentive to do this? (Can anyone say "IRIS"?) That DNS is cited all over ICANN agreements is sort of irrelevant: the DNS was specified long before ICANN was even a gleam in politicians' eyes, and ICANN was formed to allocate names in one part of the DNS. > formed ICANN, I think it was pretty clear they expected technical > specifications to handled by technical people in the IETF forum and not by > policy folks in the ICANN forum. The IETF is not the ICANN protocol-definition service. I have no idea what was supposed by those who set up ICANN, but the IETF does not have a responsibility to perform protocol-definition work for ICANN. If ICANN has an ICANN-specific protocol it needs developed, it should go and develop it on its own. (Moreover, one might be excused for thinking that part of the problem ICANN has is that it has only policy people and no technical people informing those policies. I don't actually think that, but I know lots of people who do.) So there needs to be a significant indication that the work benefits someone other than just ICANN for it to be plausible that we need a general format here. If the upshot is that there are several completely different formats to be defined, we don't need an IETF WG: the different communities of interest need to go and develop a format that fits their different needs. That said, I had the impression from the room at Anaheim that there were two other arguments in favour of taking this on in the IETF: 1. There is a wide variety of different escrow needs, and therefore a general-purpose escrow framework would be a good thing. (This has variations: some people would narrow the purpose to general Internet-registry framework, for instance. I think the more constrained the work, the more defensible.) This is roughly the argument I note above to be needed; but I didn't see a lot of people in the room clamouring for this format who weren't involved in domain name registry operations. 2. There is a serious interoperation issue here, because in the event of takeover of an Internet registry, a new operator needs to be able to get hold of the old data and read it reliably. Both of those are potentially good arguments as to why an escrow format is needed, but neither is a good argument for why it is work that belongs at the IETF. The IETF is mostly good at network protocols: things on the wire. There's really very little (no?) wire format here. (1) above actually suggests that the right place for this is some sort of data-interchange forum, of the sort that database systems people are good at. The reliability of (2) actually seems to me to require that kind of datatype expertise too, and I'm not sure the IETF is the right forum for it either. > It's clearly internet related, it's a technical specification that a known > internet community can benefit from being standardized (that we have I don't think that being Internet related or benefitting an Internet community are what the IETF is for. There's more than one completely separate standards development organization (W3C and XMPP Standards Foundation come to mind) that could also serve that goal. The IETF is good at protocols on the wire. In my view, it's less good the further from "on the wire" one gets. Apart from transmitting escrow data (which, I think, involves ssh and probably not much more), there is no wire here. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From francisco.arias@icann.org Thu Apr 22 09:41:35 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49DE33A6AE4 for ; Thu, 22 Apr 2010 09:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.986 X-Spam-Level: X-Spam-Status: No, score=-5.986 tagged_above=-999 required=5 tests=[AWL=0.613, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNT83vw8qCE0 for ; Thu, 22 Apr 2010 09:41:33 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id B9D873A6A50 for ; Thu, 22 Apr 2010 09:41:33 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 22 Apr 2010 09:41:24 -0700 From: Francisco Arias To: Krista Papac Date: Thu, 22 Apr 2010 09:41:22 -0700 Thread-Topic: [ire] Prodding by one of the chairs Thread-Index: Acrh1FusrH7Woa4lQfuFktp1zqTMvQAOWS4gAAG54nAAAIYa4AAAkeHwAAR/elAAA+eMmg== Message-ID: In-Reply-To: <1CB60B47EE74294DAC9EE08837E617E29D8E2C6655@NUMEVP11.na.imtn.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ire@ietf.org" Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 16:41:35 -0000 Krista, The data escrow spec for ICANN-accredited registrars was developed in collaboration between the registrar constituency and ICANN staff. Mike was the project leader for that effort. __=20 Francisco On 4/22/10 7:53 AM, "Krista Papac" wrote: > I am not familiar with the process that was used to develop the registrar > spec, but what I do know is the spec was developed by the Registrar Liais= on > office. Mike Zupke was responsible for executing and delivering on all > aspects Registrar Data Escrow. I "believe" he wrote the spec, but assume= he > consulted with others in the ICANN organization. >=20 > Maybe Francisco can look further into this??? >=20 > Krista Papac > Iron Mountain Digital > 5530 Bandini Blvd > Bell, CA 90201 US > Home Office: +1.714.846.8780 > Mobile: +1.714.865.7655 > Fax: +1.323.443.3573 > krista.papac@ironmountain.com >=20 > "Software Escrow for Dummies" - order your complimentary copy today at > www.ironmountain.com/escrowfordummies >=20 > New Gartner Report: Successful Software Escrow Requires Planning and > Negotiation > Gartner advises: "It is also important that the licensee continue to trac= k the > software vendor's financials and viability annually, because any signs of > financial problems would justify the cost of verification services." Cont= inue > reading the full report at: > http://www.gartner.com/technology/media-products/reprints/ironmountain/17= 0569. > html >=20 > -----Original Message----- > From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On Behalf Of Mic= hael > Young > Sent: Thursday, April 22, 2010 5:43 AM > To: 'Hollenbeck, Scott' > Cc: ire@ietf.org > Subject: Re: [ire] Prodding by one of the chairs >=20 > I can only comment as far as I have, sorry, as I did not work on the > registrar specification. Hopefully others can chime in on that piece. >=20 > Michael >=20 > -----Original Message----- > From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] > Sent: Thursday, April 22, 2010 8:36 AM > To: Michael Young > Cc: ire@ietf.org > Subject: RE: [ire] Prodding by one of the chairs >=20 >> -----Original Message----- >> From: Michael Young [mailto:myoung@ca.afilias.info] >> Sent: Thursday, April 22, 2010 8:23 AM >> To: Hollenbeck, Scott; 'David Conrad' >> Cc: ire@ietf.org >> Subject: RE: [ire] Prodding by one of the chairs >>=20 >> Scott my take on it is that there is good precedent for the >> IETF to provide the forum for the development of related >> technical specifications given past registry and DNS >> endeavors. ICANN is certainly not a body that was created >> with the idea of handling the development of said >> specifications. EPP and DNS related RFCs are directly >> referred to within all ICANN registry contracts. Some of the >> very same people that formed the IETF also helped formed >> ICANN, I think it was pretty clear they expected technical >> specifications to handled by technical people in the IETF >> forum and not by policy folks in the ICANN forum. >>=20 >> Escrow was one of the after-thoughts that I believe slipped >> through the cracks, it should have been fully developed in >> the IETF in the first place, by implementers that know what >> the consequences of what they are specifying. >> The IETF forum also allows neutral participation by ccTLD >> registry operators and registrars as well the g/sTLDs under >> operational contracts with ICANN. >>=20 >> As far as the general work goes, it meets the criteria as far >> as I can see. >> It's clearly internet related, it's a technical specification >> that a known internet community can benefit from being >> standardized (that we have interested volunteers from) and >> it's a project for which we can achieve a well defined scope >> (although like you I think this is about registry data, not >> business or financial). >>=20 >> Does that answer the question? >=20 > Incompletely - while you described the benefits of the work being done > in the IETF (assuming that the scope is narrowed to technical data I > understand those benefits), you didn't describe any issues with the > process that was used to develop the registrar specification. Did you > take part in that effort? >=20 > Original message included below for context... >=20 > Scott >=20 >> -----Original Message----- >> From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] >> Sent: Thursday, April 22, 2010 7:37 AM >> To: David Conrad >> Cc: ire@ietf.org >> Subject: Re: [ire] Prodding by one of the chairs >>=20 >>> -----Original Message----- >>> From: ire-bounces@ietf.org [mailto:ire-bounces@ietf.org] On >> Behalf Of >>> David Conrad >>> Sent: Thursday, April 22, 2010 12:29 AM >>> To: Papac, Krista >>> Cc: ire@ietf.org >>> Subject: Re: [ire] Prodding by one of the chairs >>>=20 >>> Krista, >>>=20 >>> On Apr 21, 2010, at 9:13 PM, Papac, Krista wrote: >>>> there currently aren't specs for these situations but that >>> shouldn't prevent us from creating a spec for where consistency is >>> required for these additional data fields. >>>=20 >>> I believe that's the point of the working group. >>=20 >> This touches on the thing that I still don't understand: >> there are existing specifications for registry (multiple >> formats) and registrar (standard format) data escrow that >> were developed outside the IETF using some process. Some >> people feel that there's a need for a standard registry >> escrow data format specification. Why is the process that >> was used to develop the registrar specification inadequate? >> What were the specific issues with that process that makes >> the IETF process more suitable to do the work? >>=20 >> In other words, I'd really like to ask the people who think >> that there's IETF work here to please support their position. >> For whatever it's worth, I do believe there's value in >> having a standard format for escrow of registry technical >> data. I'm less convinced of the value when we start talking >> about business and/or financial data, but we can debate that later. >>=20 >> Scott >> _______________________________________________ >> ire mailing list >> ire@ietf.org >> https://www.ietf.org/mailman/listinfo/ire >>=20 >>=20 >=20 > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire > ----------------------------------------- > The information contained in this email message and its attachments > is intended only for the private and confidential use of the > recipient(s) named above, unless the sender expressly agrees > otherwise. > Transmission of email over the Internet is not a secure > communications medium. If you are requesting or have requested the > transmittal of personal data, as defined in applicable privacy laws > by means of email or in an attachment to email, you must select a > more secure alternate means of transmittal that supports your > obligations to protect such personal data. > If the reader of this message is not the intended recipient and/or > you have received this email in error, you must take no action > based on the information in this email and you are hereby notified > that any dissemination, misuse or copying or disclosure of this > communication is strictly prohibited. If you have received this > communication in error, please notify us immediately by email and > delete the original message. > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire >=20 From pk@DENIC.DE Thu Apr 22 12:09:46 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640323A681A for ; Thu, 22 Apr 2010 12:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.372 X-Spam-Level: X-Spam-Status: No, score=-3.372 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYQg+bdmbex2 for ; Thu, 22 Apr 2010 12:09:45 -0700 (PDT) Received: from office.denic.de (gw-office.denic.de [81.91.160.182]) by core3.amsl.com (Postfix) with ESMTP id F12B83A6959 for ; Thu, 22 Apr 2010 11:46:25 -0700 (PDT) Received: from unknown.office.denic.de ([10.122.65.91]) by office.denic.de with esmtp id 1O51Pj-0004Zo-57; Thu, 22 Apr 2010 20:46:15 +0200 Received: by unknown.office.denic.de (Postfix, from userid 501) id 186C05BE53A; Thu, 22 Apr 2010 20:46:14 +0200 (CEST) Date: Thu, 22 Apr 2010 20:46:14 +0200 From: Peter Koch To: ire@ietf.org Message-ID: <20100422184614.GJ9273@unknown.office.denic.de> Mail-Followup-To: ire@ietf.org References: <82F87B34-C652-44BB-95CE-0C25659AB3F3@virtualized.org> <046F43A8D79C794FA4733814869CDF070331E435@dul1wnexmb01.vcorp.ad.vrsn.com> <001501cae216$94901970$bdb04c50$@afilias.info> <20100422163335.GG1362@shinkuro.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100422163335.GG1362@shinkuro.com> User-Agent: Mutt/1.4.2.1i Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:09:46 -0000 On Thu, Apr 22, 2010 at 12:33:36PM -0400, Andrew Sullivan wrote: > I think I agree with Scott that the arguments in favour of a WG to > undertake work in this area still seem underwhelming. I would like to join this point of view. > We had a bar BOF at Anaheim in which people were arguing that a number > of different, incompatible extensions have emerged under EPP. One way > to interpret that state of affairs is that the IETF ought to undertake > to unify the specifications. But _another_ way to look at the > evidence is that EPP worked: it's extensible, and people have added a > lot of extensions because they had different local needs. In the same The problem here is that either the proposed work has to lean itself towards a particular segment of the registration/domain industry or it has to be so flexible (extensible, if you wish) that the outcome might be a framework only where the gory details happen in local customizations all over the place. > The IETF is not the ICANN protocol-definition service. I have no idea Nicely put. Agree with this, except that I doubt ... > what was supposed by those who set up ICANN, but the IETF does not > have a responsibility to perform protocol-definition work for ICANN. > If ICANN has an ICANN-specific protocol it needs developed, it should > go and develop it on its own. ... this is the right next step, depending on how "specific" it is. First, i currently can't see we are really talking about protocol development, but rather data formats. Second, external timelines don't play well with IETF process (or vice versa). Third, it is still unclear to me _what_ ought to be dealt with, which needs to be defined before addressing any formats. We've heard "technical registration data" to "anything that allows continuation or re-instatiation of services". > needs to be a significant indication that the work benefits someone > other than just ICANN for it to be plausible that we need a general > format here. If the upshot is that there are several completely > different formats to be defined, we don't need an IETF WG: the +1; > systems people are good at. The reliability of (2) actually seems to > me to require that kind of datatype expertise too, and I'm not sure > the IETF is the right forum for it either. Neither am I, but to emphasize: this is not to send anybody elsewhere just to avoid the work being done in the IETF. Finding the appropriate venue is second to determining that there's standards work to do at all. If that's positive, the IETF is probably not the worst candidate to look at. -Peter From drc@virtualized.org Thu Apr 22 12:14:06 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 615A228C253 for ; Thu, 22 Apr 2010 12:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NavG5Gs9r6cI for ; Thu, 22 Apr 2010 12:14:05 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 624E928C2ED for ; Thu, 22 Apr 2010 11:55:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id C7FF6BBB571; Thu, 22 Apr 2010 11:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1QnkXC30SuQ; Thu, 22 Apr 2010 11:55:24 -0700 (PDT) Received: from [172.18.185.231] (unknown [12.19.192.7]) by virtualized.org (Postfix) with ESMTP id E754FBBB55D; Thu, 22 Apr 2010 11:55:23 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <20100422163335.GG1362@shinkuro.com> Date: Thu, 22 Apr 2010 11:55:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5592434F-9C0B-4C70-BE41-71ADB740F81F@virtualized.org> References: <82F87B34-C652-44BB-95CE-0C25659AB3F3@virtualized.org> <046F43A8D79C794FA4733814869CDF070331E435@dul1wnexmb01.vcorp.ad.vrsn.com> <001501cae216$94901970$bdb04c50$@afilias.info> <20100422163335.GG1362@shinkuro.com> To: Andrew Sullivan X-Mailer: Apple Mail (2.1078) Cc: ire@ietf.org Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:14:06 -0000 On Apr 22, 2010, at 9:33 AM, Andrew Sullivan wrote: > But _another_ way to look at the > evidence is that EPP worked: it's extensible, and people have added a > lot of extensions because they had different local needs. In the same > way, the multiplicity of escrow formats could reasonably be > interpreted as an indication that different agreements required > different responses, and therefore the escrow rules are different. This would appear to argue that the nice thing about standards is there = are so many to choose from. I believe the difference here is that = extensions to EPP are done within a defined framework that was specified = created to facilitate them. The different escrow formats is, I believe, = a function of organic growth without much thought as to what was being = grown. > So there > needs to be a significant indication that the work benefits someone > other than just ICANN for it to be plausible that we need a general > format here. So, the issue here is a bit subtle. ICANN's interest in a data escrow = format is because we require contracted parties to escrow data -- my = impression is that we're trying to make lives easier for those parties. = ICANN (mostly) doesn't care about the format because we aren't the folks = who need to generate and consume the data -- the contracted registries = and registrars are. However, I personally believe that if a generalized = format was defined, other folks (non-contracted DNS registries, address = registries, etc.) would see benefit in making use it. > 1. There is a wide variety of different escrow needs, and therefore a > general-purpose escrow framework would be a good thing.=20 > ... > 2. There is a serious interoperation issue here > ... > Both of those are potentially good arguments as to why an escrow > format is needed, but neither is a good argument for why it is work > that belongs at the IETF. The IETF is mostly good at network > protocols: things on the wire. There's really very little (no?) wire > format here. An interesting distinction and one I'm not sure I agree with. Your = observation would appear to disallow efforts such as NETCONF from being = discussed within the IETF. The IETF has a long, robust history of = defining data formats from the master file format to IANA registries to = IDN tables. I'm not sure I see the difference. Regards, -drc From ajs@shinkuro.com Thu Apr 22 12:34:11 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF073A69FD for ; Thu, 22 Apr 2010 12:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.834 X-Spam-Level: X-Spam-Status: No, score=-0.834 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrH43bDC0VZt for ; Thu, 22 Apr 2010 12:34:10 -0700 (PDT) Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 6B73B3A6A98 for ; Thu, 22 Apr 2010 12:20:38 -0700 (PDT) Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 7EA221ECB400 for ; Thu, 22 Apr 2010 19:20:27 +0000 (UTC) Date: Thu, 22 Apr 2010 15:20:25 -0400 From: Andrew Sullivan To: ire@ietf.org Message-ID: <20100422192025.GN1362@shinkuro.com> References: <82F87B34-C652-44BB-95CE-0C25659AB3F3@virtualized.org> <046F43A8D79C794FA4733814869CDF070331E435@dul1wnexmb01.vcorp.ad.vrsn.com> <001501cae216$94901970$bdb04c50$@afilias.info> <20100422163335.GG1362@shinkuro.com> <20100422184614.GJ9273@unknown.office.denic.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100422184614.GJ9273@unknown.office.denic.de> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:34:11 -0000 On Thu, Apr 22, 2010 at 08:46:14PM +0200, Peter Koch wrote: > Neither am I, but to emphasize: this is not to send anybody elsewhere > just to avoid the work being done in the IETF. Finding the appropriate > venue is second to determining that there's standards work to do at all. I agree with this, but I do worry about the expertise issues. Speaking as a recovering database geek, I actually find the "storage" data formats that the IETF has previously come up with to be somewhat awkward. It would be awful nice to get real database eyes on any escrow format (since the database people are going to have to produce and consume it), and I have doubts we have a lot of those hereabouts. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. From drc@virtualized.org Thu Apr 22 12:34:29 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7699F3A6A0D for ; Thu, 22 Apr 2010 12:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDkvrow4ABRd for ; Thu, 22 Apr 2010 12:34:28 -0700 (PDT) Received: from virtualized.org (trantor.virtualized.org [204.152.189.190]) by core3.amsl.com (Postfix) with ESMTP id 71CDE3A68C5 for ; Thu, 22 Apr 2010 12:21:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virtualized.org (Postfix) with ESMTP id AB93ABBB7C3; Thu, 22 Apr 2010 12:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at virtualized.org Received: from virtualized.org ([127.0.0.1]) by localhost (trantor.virtualized.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hL7y9HOLvzi; Thu, 22 Apr 2010 12:20:54 -0700 (PDT) Received: from [172.18.185.231] (unknown [12.19.192.7]) by virtualized.org (Postfix) with ESMTP id B9C51BBB7AE; Thu, 22 Apr 2010 12:20:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: David Conrad In-Reply-To: <20100422184614.GJ9273@unknown.office.denic.de> Date: Thu, 22 Apr 2010 12:20:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <82F87B34-C652-44BB-95CE-0C25659AB3F3@virtualized.org> <046F43A8D79C794FA4733814869CDF070331E435@dul1wnexmb01.vcorp.ad.vrsn.com> <001501cae216$94901970$bdb04c50$@afilias.info> <20100422163335.GG1362@shinkuro.com> <20100422184614.GJ9273@unknown.office.denic.de> To: Peter Koch X-Mailer: Apple Mail (2.1078) Cc: ire@ietf.org Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:34:29 -0000 Peter, On Apr 22, 2010, at 11:46 AM, Peter Koch wrote: > The problem here is that either the proposed work has to lean itself > towards a particular segment of the registration/domain industry or it > has to be so flexible (extensible, if you wish) that the outcome might > be a framework only where the gory details happen in local = customizations > all over the place. My impression is that core registration data is fairly consistent across = pretty much everything that might be registered, e.g., name, address, = contact information, expiration, etc. Yes, extensions off that core can = be wildly varying. Regards, -drc From myoung@ca.afilias.info Thu Apr 22 12:51:18 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12F3B3A6826 for ; Thu, 22 Apr 2010 12:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.406 X-Spam-Level: X-Spam-Status: No, score=-4.406 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRG+nBIYq6Ip for ; Thu, 22 Apr 2010 12:51:15 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 3B68F3A62C1 for ; Thu, 22 Apr 2010 12:46:05 -0700 (PDT) Received: from ms6.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1O52LS-0008Ng-4w; Thu, 22 Apr 2010 19:45:54 +0000 Received: from tor-gateway.afilias.info ([199.15.87.4] helo=DUN345) by smtp.afilias.info with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1O52LS-0003ql-7e; Thu, 22 Apr 2010 19:45:54 +0000 From: "Michael Young" To: "'Andrew Sullivan'" , References: <82F87B34-C652-44BB-95CE-0C25659AB3F3@virtualized.org> <046F43A8D79C794FA4733814869CDF070331E435@dul1wnexmb01.vcorp.ad.vrsn.com> <001501cae216$94901970$bdb04c50$@afilias.info> <20100422163335.GG1362@shinkuro.com> <20100422184614.GJ9273@unknown.office.denic.de> <20100422192025.GN1362@shinkuro.com> In-Reply-To: <20100422192025.GN1362@shinkuro.com> Date: Thu, 22 Apr 2010 15:45:48 -0400 Message-ID: <02c501cae254$68606b00$39214100$@afilias.info> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcriUscojijdl5L+TIuvMOD/Lgf5WAAAXcvg Content-Language: en-ca Subject: Re: [ire] Prodding by one of the chairs X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Apr 2010 19:51:18 -0000 BTW some of the draft work submitted for consideration was done by Chris Browne - so that's at least one! -----Original Message----- From: Andrew Sullivan [mailto:ajs@shinkuro.com] Sent: April-22-10 3:20 PM To: ire@ietf.org Subject: Re: [ire] Prodding by one of the chairs On Thu, Apr 22, 2010 at 08:46:14PM +0200, Peter Koch wrote: > Neither am I, but to emphasize: this is not to send anybody elsewhere > just to avoid the work being done in the IETF. Finding the appropriate > venue is second to determining that there's standards work to do at all. I agree with this, but I do worry about the expertise issues. Speaking as a recovering database geek, I actually find the "storage" data formats that the IETF has previously come up with to be somewhat awkward. It would be awful nice to get real database eyes on any escrow format (since the database people are going to have to produce and consume it), and I have doubts we have a lot of those hereabouts. A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc. _______________________________________________ ire mailing list ire@ietf.org https://www.ietf.org/mailman/listinfo/ire From Ed.Lewis@neustar.biz Fri Apr 23 06:51:59 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C766C3A68E0 for ; Fri, 23 Apr 2010 06:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.101 X-Spam-Level: ** X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_80=2, J_CHICKENPOX_56=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENfvs1qp+H7F for ; Fri, 23 Apr 2010 06:51:58 -0700 (PDT) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 730593A67D7 for ; Fri, 23 Apr 2010 06:51:58 -0700 (PDT) Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o3NDpdeK041712; Fri, 23 Apr 2010 09:51:40 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz) Received: from [10.31.200.147] by Work-Laptop-2.local (PGP Universal service); Fri, 23 Apr 2010 09:51:46 -0400 X-PGP-Universal: processed; by Work-Laptop-2.local on Fri, 23 Apr 2010 09:51:46 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 23 Apr 2010 09:50:39 -0400 To: ire@ietf.org From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: [ire] The ICANN-IETF dynamic and escrow X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 13:51:59 -0000 From reading the discussion on the list, in an effort to try and come to a consensus and not drag us into the epic battle of words over ICANN and anyone else...oh, if I have incorrectly stated anything here, please speak up. The role of the chair is to try to capture what's being said, and not "make things up." (I will note that not all of what I said here is strictly from the list, I added some background to the discussion to try to fill in the points made.) In some sense, ICANN does look to the IETF as the protocol defining body[0]. This is not meant to be interpreted as the IETF is to build to what ICANN specifies, rather that ICANN sets up high-level requirements and seeks out the IETF to help fulfill the need. Further, ICANN recognizes that it is not an all-encompassing body overseeing the business of registering identifiers on the Internet. The closest Internet organization that is all-encompassing - in the sense that anyone is accommodated regardless of any criteria - is the IETF. So, ICANN turns to the IETF for solutions that will have impacts exceeding it's boundaries and to gain a wider review than it is capable of providing. As a chair, I'd like to set side that this issue came from ICANN as a red herring (a distraction) from the matter at hand. In this instance, ICANN has come forth with a general problem statement, a sample of what they came up with on their own, and with a "captive audience" that they will require to operate to what the IETF can generate. It's important to note that this is not sufficient justify that the work is done in the IETF. The IETF is not beholden to ICANN. The IETF criteria for taking on work still apply. And to me the number one criteria, summed up in one word is "interoperability." References to previous ICANN-born work that came to the IETF are valid data points and valid for letting us learn what makes an effort successful or not. With EPP one lesson was that wide review is good, but wider would be better. IRIS saw that once the protocol was defined, it matters more if there is a real need for it. But you can also find these same lessons in work born elsewhere. E.g., DNSSEC didn't become popular with operations until Dan Kaminsky's research years after the protocol had gelled. And we have many other protocols that haven't "caught fire." [0] Historically, ICANN did envision IETF as the PSO (Protocol Supporting Organization), to go along with the ASO (Address) and NSO? (names?). For the historical record - http://www.icann.org/pso/psonew.htm . The ASO is alive and kicking (a whole'nuhter matter), I don't know what became of the name support organization because I don't normally hang around "ICANN." The PSO, so far as I know, is an idea that expired a long time ago, put perhaps the proposal from 10+ years ago is what drives the thought that ICANN sees IETF as one of it's components. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Wouldn't it be nice if all of the definitions of equivalence were the same? From paul.hoffman@vpnc.org Fri Apr 23 07:43:34 2010 Return-Path: X-Original-To: ire@core3.amsl.com Delivered-To: ire@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F0BE3A68A5 for ; Fri, 23 Apr 2010 07:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.366 X-Spam-Level: X-Spam-Status: No, score=-1.366 tagged_above=-999 required=5 tests=[AWL=-1.920, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kT7kzkahGTHc for ; Fri, 23 Apr 2010 07:43:33 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id DD3663A68B5 for ; Fri, 23 Apr 2010 07:43:30 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o3NEhIdw009683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Apr 2010 07:43:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 23 Apr 2010 07:43:17 -0700 To: Edward Lewis , ire@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [ire] The ICANN-IETF dynamic and escrow X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 14:43:34 -0000 At 9:50 AM -0400 4/23/10, Edward Lewis wrote: >It's important to note that this is not sufficient justify that the work is done in the IETF. The IETF is not beholden to ICANN. The IETF criteria for taking on work still apply. And to me the number one criteria, summed up in one word is "interoperability." For me, the number two criterion is "ability", as in "is the IETF able to do this work". If we were talking about a protocol, I would say "yes". But we are not talking about a protocol, it seems: we are talking about a data format and a set of semantics for the entries in that format. The IETF has a long track record of wheel-spinning and rathole-finding we discuss formats. We do even worse when we try to specify semantics for things like people and businesses. ICANN already has developed internally a data format and set of semantics that are adequate for their needs. If they want to improve them, they can probably do that internally as well, or they can use their normal practices to invite experts to help them. What's left is whether an IETF-generated data format help other constituencies, such as for the address registries. It might, certainly, but it also might not, given our poor track record in the field. Anyone can write an XML or JSON or ASN.1 or CSV schema; anyone can specify their own semantics. If the idea is to promote interoperability, publishing informational RFCs through the independent submissions stream is an excellent way to do that. A reasonable handful of those RFCs are, in fact, data schemas with semantics. --Paul Hoffman, Director --VPN Consortium