From Ed.Lewis@neustar.biz Thu Jan 21 11:53:48 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 F31E228C1A6 for ; Thu, 21 Jan 2010 11:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_00=-2.599, HTML_MESSAGE=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 fO7ucn3f6E52 for ; Thu, 21 Jan 2010 11:53:47 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 18AFA3A68D9 for ; Thu, 21 Jan 2010 11:53:44 -0800 (PST) Received: from [10.31.200.228] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0LJrdWE011126; Thu, 21 Jan 2010 14:53:39 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Thu, 21 Jan 2010 14:53:37 -0500 To: ire@ietf.org From: Edward Lewis Content-Type: multipart/alternative; boundary="============_-948018877==_ma============" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: ed.lewis@neustar.biz Subject: [ire] The first message 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, 21 Jan 2010 19:53:48 -0000 --============_-948018877==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" This list is for discussions related to the development and implementation of an escrow protocol for domain registration information. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. --============_-948018877==_ma============ Content-Type: text/html; charset="us-ascii" The first message
This list is for discussions related to the development and implementation of an escrow protocol for domain registration information.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.
--============_-948018877==_ma============-- From bortzmeyer@nic.fr Fri Jan 22 02:33:23 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 8FD733A6958 for ; Fri, 22 Jan 2010 02:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=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 GUD3y4Pa6dUG for ; Fri, 22 Jan 2010 02:33:23 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [IPv6:2001:660:3003:2::4:11]) by core3.amsl.com (Postfix) with ESMTP id CA0143A690C for ; Fri, 22 Jan 2010 02:33:22 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 062721C0603 for ; Fri, 22 Jan 2010 11:33:18 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 01FC81C0602 for ; Fri, 22 Jan 2010 11:33:18 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id EB102A1D9B0 for ; Fri, 22 Jan 2010 11:33:17 +0100 (CET) Date: Fri, 22 Jan 2010 11:33:17 +0100 From: Stephane Bortzmeyer To: ire@ietf.org Message-ID: <20100122103317.GA15831@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: Debian GNU/Linux 5.0.3 X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Subject: [ire] Protocol or format? 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, 22 Jan 2010 10:33:23 -0000 Ed Lewis, in his first message, mentioned a protocol. I thought the idea was to devise a format? I don't think a common protocol is realistic. From JGould@verisign.com Fri Jan 22 05:37:04 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 80E503A69D2 for ; Fri, 22 Jan 2010 05:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.024 X-Spam-Level: X-Spam-Status: No, score=-1.024 tagged_above=-999 required=5 tests=[AWL=1.578, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 CTY+cdHSMm5m for ; Fri, 22 Jan 2010 05:37:03 -0800 (PST) Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by core3.amsl.com (Postfix) with ESMTP id 8FFC13A69CB for ; Fri, 22 Jan 2010 05:37:03 -0800 (PST) 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 o0MDWBSJ001650; Fri, 22 Jan 2010 08:32:11 -0500 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 08:36:58 -0500 Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 22 Jan 2010 13:36:58 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 22 Jan 2010 08:36:55 -0500 From: James Gould To: Stephane Bortzmeyer , Message-ID: Thread-Topic: [ire] Protocol or format? Thread-Index: AcqbTlJsO0cpeP14T3W5utvEBmgFeQAGaPmv In-Reply-To: <20100122103317.GA15831@nic.fr> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3346994217_7423522" X-OriginalArrivalTime: 22 Jan 2010 13:36:58.0722 (UTC) FILETIME=[F88A2420:01CA9B67] Subject: Re: [ire] Protocol or format? 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, 22 Jan 2010 13:37:04 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3346994217_7423522 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I concur. I believe that it would be a common file format and also a common transport for the file. Is this the case? -- JG ------------------------------------------------------- James F. Gould Principal Software Engineer VeriSign Naming Services jgould@verisign.com Direct: 703.948.3271 Mobile: 703.628.7063 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior written consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you. From: Stephane Bortzmeyer Organization: NIC France Date: Fri, 22 Jan 2010 05:33:17 -0500 To: Subject: [ire] Protocol or format? Ed Lewis, in his first message, mentioned a protocol. I thought the idea was to devise a format? I don't think a common protocol is realistic. _______________________________________________ ire mailing list ire@ietf.org https://www.ietf.org/mailman/listinfo/ire --B_3346994217_7423522 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [ire] Protocol or format? I concur.  I believe that it would be a common file format and also a= common transport for the file.  Is this the case?    
--


JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet= ary and/or Registry  Sensitive information intended solely for the reci= pient and, thus may not be  retransmitted, reproduced or disclosed with= out the prior written consent of  VeriSign Naming and Directory Service= s.  If you have received  this e-mail message in error, please = notify the sender immediately by  telephone or reply e-mail and destroy= the original message without making a  copy.  Thank you.



From: Stephane Bortzmeyer <= bortzmeyer@nic.fr>
Organization: NIC France
Date: Fri, 22 Jan 2010 05:33:17 -0500
To: <ire@ietf.org>
Subject: [ire] Protocol or format?

Ed Lewis, in his first message, mentioned a protocol. I thought the
idea was to devise a format? I don't think a common protocol is
realistic.
_______________________________________________
ire mailing list
ire@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ire

--B_3346994217_7423522-- From jgalvin@afilias.info Fri Jan 22 05:45:00 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 C6ADC3A69E9 for ; Fri, 22 Jan 2010 05:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.615 X-Spam-Level: X-Spam-Status: No, score=-5.615 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, 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 CIkSL6klpWou for ; Fri, 22 Jan 2010 05:45:00 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 6F0A83A67A4 for ; Fri, 22 Jan 2010 05:44:56 -0800 (PST) Date: Fri, 22 Jan 2010 08:45:16 -0500 From: James M Galvin To: ire@ietf.org Message-ID: <8F0CB163A47448DD2F7895A1@James-Galvin.local> In-Reply-To: <20100122103317.GA15831@nic.fr> References: <20100122103317.GA15831@nic.fr> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Authenticated: True Subject: Re: [ire] Protocol or format? 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, 22 Jan 2010 13:45:00 -0000 It's about the data itself more so than the format. What is it that needs to be escrowed? Then it's the format and the transport. Jim -- On January 22, 2010 11:33:17 AM +0100 Stephane Bortzmeyer wrote regarding [ire] Protocol or format? -- > Ed Lewis, in his first message, mentioned a protocol. I thought the > idea was to devise a format? I don't think a common protocol is > realistic. > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire From bortzmeyer@nic.fr Fri Jan 22 06:04:45 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 3CA933A6A19 for ; Fri, 22 Jan 2010 06:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=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 dXeKO0zOCM+r for ; Fri, 22 Jan 2010 06:04:44 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 46E243A689D for ; Fri, 22 Jan 2010 06:04:44 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 04F841C0675; Fri, 22 Jan 2010 14:59:39 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 002EE1C0636; Fri, 22 Jan 2010 14:59:39 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id E8DECA1D9AF; Fri, 22 Jan 2010 14:59:38 +0100 (CET) Date: Fri, 22 Jan 2010 14:59:38 +0100 From: Stephane Bortzmeyer To: James Gould Message-ID: <20100122135938.GA8610@nic.fr> References: <20100122103317.GA15831@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 5.0.3 X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ire@ietf.org Subject: Re: [ire] Protocol or format? 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, 22 Jan 2010 14:04:45 -0000 On Fri, Jan 22, 2010 at 08:36:55AM -0500, James Gould wrote a message of 127 lines which said: > I believe that it would be a common file format and also a common > transport for the file. That's not my vision. We need to specify the data (as said by James M Galvin) then the format but we may leave the transport unspecified, escrowing is typically not a real-time process and does not require an official transport (rsync or DVD are fine for me). From JGould@verisign.com Fri Jan 22 06:31:54 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 9FAEB3A67DB for ; Fri, 22 Jan 2010 06:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=2.653, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 ZF2RecHbQEJe for ; Fri, 22 Jan 2010 06:31:49 -0800 (PST) Received: from peregrine.verisign.com (peregrine.verisign.com [216.168.239.74]) by core3.amsl.com (Postfix) with ESMTP id 571933A67BD for ; Fri, 22 Jan 2010 06:31:49 -0800 (PST) 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 o0MEQutq003798; Fri, 22 Jan 2010 09:26:56 -0500 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 09:31:44 -0500 Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 22 Jan 2010 14:31:43 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 22 Jan 2010 09:31:37 -0500 From: James Gould To: James M Galvin , Message-ID: Thread-Topic: [ire] Protocol or format? Thread-Index: AcqbaReHhq7PqmlwQZyD3idPvX0rVQABoMH9 In-Reply-To: <8F0CB163A47448DD2F7895A1@James-Galvin.local> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3346997498_7645936" X-OriginalArrivalTime: 22 Jan 2010 14:31:44.0181 (UTC) FILETIME=[9ED36650:01CA9B6F] Subject: Re: [ire] Protocol or format? 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, 22 Jan 2010 14:31:54 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3346997498_7645936 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Yes, I agree that the data comes first (what and how much). The format of the data is also important to ensure that software can be written that can easily process any escrow data deposited. The transport is less of an issue, but it would be good if there was an agreed upon secure transport fo= r the escrow data. Are the files encrypted, are they unencrypted and passed across an encrypted transport, or a combination. My concern is related to the encryption of the data itself to again ensure that software can easily process escrowed data in a standard and =B3secure=B2 manor. --=20 JG=20 ------------------------------------------------------- James F. Gould Principal Software Engineer VeriSign Naming Services jgould@verisign.com Direct: 703.948.3271 Mobile: 703.628.7063 =20 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior writte= n consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you. From: James M Galvin Date: Fri, 22 Jan 2010 08:45:16 -0500 To: Subject: Re: [ire] Protocol or format? It's about the data itself more so than the format. What is it that needs to be escrowed? Then it's the format and the transport. Jim -- On January 22, 2010 11:33:17 AM +0100 Stephane Bortzmeyer wrote regarding [ire] Protocol or format? -- > Ed Lewis, in his first message, mentioned a protocol. I thought the > idea was to devise a format? I don't think a common protocol is > realistic. > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire _______________________________________________ ire mailing list ire@ietf.org https://www.ietf.org/mailman/listinfo/ire --B_3346997498_7645936 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [ire] Protocol or format? Yes, I agree that the data comes first (what and how much).  The form= at of the data is also important to ensure that software can be written that= can easily process any escrow data deposited.    The transpo= rt is less of an issue, but it would be good if there was an agreed upon sec= ure transport for the escrow data.  Are the files encrypted, are they u= nencrypted and passed across an encrypted transport, or a combination.  = ;My concern is related to the encryption of the data itself to again ensure = that software can easily process escrowed data in a standard and “secu= re” manor.     

--


JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet= ary and/or Registry  Sensitive information intended solely for the reci= pient and, thus may not be  retransmitted, reproduced or disclosed with= out the prior written consent of  VeriSign Naming and Directory Service= s.  If you have received  this e-mail message in error, please = notify the sender immediately by  telephone or reply e-mail and destroy= the original message without making a  copy.  Thank you.



From: James M Galvin <jgalvin@afilias.info>
Date: Fri, 22 Jan 2010 08:45:16 -0500
To: <ire@ietf.org>
Subject: Re: [ire] Protocol or format?

It's about the data itself more so than the format.  What is it that needs to be escrowed?  Then it's the format and the transport.

Jim



-- On January 22, 2010 11:33:17 AM +0100 Stephane Bortzmeyer
<bortzmeyer@nic.fr> wrote regarding [= ire] Protocol or format? --

> Ed Lewis, in his first message, mentioned a protocol. I thought the > idea was to devise a format? I don't think a common protocol is
> realistic.
> _______________________________________________
> ire mailing list
> ire@ietf.org
> https://www.ietf.o= rg/mailman/listinfo/ire


_______________________________________________
ire mailing list
ire@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ire

--B_3346997498_7645936-- From jcurran@arin.net Fri Jan 22 06:37: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 8A97D3A67DB for ; Fri, 22 Jan 2010 06:37:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[AWL=-0.867, 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 f242A5bLxNlY for ; Fri, 22 Jan 2010 06:37:24 -0800 (PST) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by core3.amsl.com (Postfix) with ESMTP id 225A63A6A20 for ; Fri, 22 Jan 2010 06:37:24 -0800 (PST) Received: by smtp1.arin.net (Postfix, from userid 323) id 168E9165073; Fri, 22 Jan 2010 09:37:20 -0500 (EST) Received: from ex.arin.net (ex.arin.net [192.136.136.237]) by smtp1.arin.net (Postfix) with ESMTP id E6A2F164EAB for ; Fri, 22 Jan 2010 09:37:19 -0500 (EST) Received: from EDAMAME.arin.net ([192.136.136.194]) by ex.arin.net ([192.136.136.237]) with mapi; Fri, 22 Jan 2010 09:37:19 -0500 From: John Curran To: "ire@ietf.org" Date: Fri, 22 Jan 2010 09:37:18 -0500 Thread-Topic: [ire] Protocol or format? Thread-Index: AcqbcGarE3EBAVAjSQGfxNNa6eudTQ== Message-ID: References: <20100122103317.GA15831@nic.fr> In-Reply-To: <20100122103317.GA15831@nic.fr> 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 Subject: Re: [ire] Protocol or format? 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, 22 Jan 2010 14:37:26 -0000 Some IRE Charter Questions -=20 Scope=20 - Internet resource registry data in general, or=20 just registry data needed for escrow purposes? i.e. Presently the RIR's publish 'daily files', containing summaries of number resource changes for each day, these files are used for statistics=20 and for informing the operational/security community=20 about resource allocations. The RIR's have worked to bring about more commonality on publication=20 format; would this also be a potential use for=20 the format being considered by the working group,=20 or it is specifically targeted at escrow purposes? - Public Internet resource registry data, or also=20 private/NDA data and/or metadata? =20 While we all know what shows up in WHOIS, there's=20 actually quite a bit of data behind the scenes regarding allocation and change history which is not visible but still important to have, and then there's related private information which is part of the resource request history. How much of this is being considered in the data format? - Incremental updates in scope of format or not? If we're focusing on formats and have protocol=20 out of scope, it may be necessary to determine=20 if incremental escrow updates are in scope (and hence require us to include necessary sync data) or whether this is purely a protocol matter. Many of the above issues might be clarified by=20 elaborating a problem statement or use cases... Thanks, /John From JGould@verisign.com Fri Jan 22 07:14:01 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 A85C23A68DA for ; Fri, 22 Jan 2010 07:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.881 X-Spam-Level: X-Spam-Status: No, score=-2.881 tagged_above=-999 required=5 tests=[AWL=2.321, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 bvRRtWTCkVVW for ; Fri, 22 Jan 2010 07:13:54 -0800 (PST) Received: from osprey.verisign.com (osprey.verisign.com [216.168.239.75]) by core3.amsl.com (Postfix) with ESMTP id 67DF63A681D for ; Fri, 22 Jan 2010 07:13:53 -0800 (PST) Received: from dul1wnexcn04.vcorp.ad.vrsn.com (dul1wnexcn04.vcorp.ad.vrsn.com [10.170.12.139]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id o0MEt6Vb028717; Fri, 22 Jan 2010 09:55:06 -0500 Received: from dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) by dul1wnexcn04.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Jan 2010 10:13:46 -0500 Received: from 10.131.29.63 ([10.131.29.63]) by dul1wnexmb01.vcorp.ad.vrsn.com ([10.170.12.134]) with Microsoft Exchange Server HTTP-DAV ; Fri, 22 Jan 2010 15:13:45 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Fri, 22 Jan 2010 10:13:42 -0500 From: James Gould To: John Curran , Message-ID: Thread-Topic: [ire] Protocol or format? Thread-Index: AcqbcGarE3EBAVAjSQGfxNNa6eudTQABRTnU In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3347000023_7755328" X-OriginalArrivalTime: 22 Jan 2010 15:13:46.0511 (UTC) FILETIME=[7E4069F0:01CA9B75] Subject: Re: [ire] Protocol or format? 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, 22 Jan 2010 15:14:01 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3347000023_7755328 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable John, I would see the data as being full and partial registry data that represent= s all of the registered data (domains, hosts, etc.), the relationships, the sponsorship information (Registrar information) of the objects, and finally any additional meta-data needed to reconstitute the data. I don=B9t see the summary data as being in scope. I=B9m assuming data like private keys held i= n HSM=B9s for DNSSEC signing is not included. The full deposit could be done less frequently (i.e. Weekly) and the partial deposits would include the delta changes more frequently (i.e. Daily). I see the deposits as files following a pre-defined file format and hopefully secured in a standard way= . --=20 JG=20 ------------------------------------------------------- James F. Gould Principal Software Engineer VeriSign Naming Services jgould@verisign.com Direct: 703.948.3271 Mobile: 703.628.7063 =20 21345 Ridgetop Circle LS2-2-1 Dulles, VA 20166 Notice to Recipient: This e-mail contains confidential, proprietary and/or Registry Sensitive information intended solely for the recipient and, thus may not be retransmitted, reproduced or disclosed without the prior writte= n consent of VeriSign Naming and Directory Services. If you have received this e-mail message in error, please notify the sender immediately by telephone or reply e-mail and destroy the original message without making a copy. Thank you. From: John Curran Date: Fri, 22 Jan 2010 09:37:18 -0500 To: Subject: Re: [ire] Protocol or format? Some IRE Charter Questions - Scope - Internet resource registry data in general, or just registry data needed for escrow purposes? i.e. Presently the RIR's publish 'daily files', containing summaries of number resource changes for each day, these files are used for statistics and for informing the operational/security community about resource allocations. The RIR's have worked to bring about more commonality on publication format; would this also be a potential use for the format being considered by the working group, or it is specifically targeted at escrow purposes? - Public Internet resource registry data, or also private/NDA data and/or metadata? While we all know what shows up in WHOIS, there's actually quite a bit of data behind the scenes regarding allocation and change history which is not visible but still important to have, and then there's related private information which is part of the resource request history. How much of this is being considered in the data format? - Incremental updates in scope of format or not? If we're focusing on formats and have protocol out of scope, it may be necessary to determine if incremental escrow updates are in scope (and hence require us to include necessary sync data) or whether this is purely a protocol matter. Many of the above issues might be clarified by elaborating a problem statement or use cases... Thanks, /John _______________________________________________ ire mailing list ire@ietf.org https://www.ietf.org/mailman/listinfo/ire --B_3347000023_7755328 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [ire] Protocol or format? John,

I would see the data as being full and partial registry data that represent= s all of the registered data (domains, hosts, etc.), the relationships, the = sponsorship information (Registrar information) of the objects, and finally = any additional meta-data needed to reconstitute the data.  I don’= t see the summary data as being in scope.  I’m assuming data like= private keys held in HSM’s for DNSSEC signing is not included.  = The full deposit could be done less frequently (i.e. Weekly) and the partial= deposits would include the delta changes more frequently (i.e. Daily). &nbs= p;I see the deposits as files following a pre-defined file format and hopefu= lly secured in a standard way.        &nb= sp;

--


JG

-------------------------------------------------------
James F. Gould
Principal Software Engineer
VeriSign Naming Services
jgould@verisign.com
Direct: 703.948.3271
Mobile: 703.628.7063

 
21345 Ridgetop Circle
LS2-2-1
Dulles, VA 20166

Notice to Recipient:  This e-mail contains confidential, propriet= ary and/or Registry  Sensitive information intended solely for the reci= pient and, thus may not be  retransmitted, reproduced or disclosed with= out the prior written consent of  VeriSign Naming and Directory Service= s.  If you have received  this e-mail message in error, please = notify the sender immediately by  telephone or reply e-mail and destroy= the original message without making a  copy.  Thank you.



From: John Curran <jcurran@arin.net>
Date: Fri, 22 Jan 2010 09:37:18 -0500
To: <ire@ietf.org>
Subject: Re: [ire] Protocol or format?

Some IRE Charter Questions -

Scope

- Internet resource registry data in general, or
 just registry data needed for escrow purposes?

 i.e.  Presently the RIR's publish 'daily files',
 containing summaries of number resource changes
 for each day, these files are used for statistics
 and for informing the operational/security community
 about resource allocations.  The RIR's have worked
 to bring about more commonality on publication
 format; would this also be a potential use for
 the format being considered by the working group,
 or it is specifically targeted at escrow purposes?

- Public Internet resource registry data, or also
 private/NDA data and/or metadata?

 While we all know what shows up in WHOIS, there's
 actually quite a bit of data behind the scenes
 regarding allocation and change history which is
 not visible but still important to have, and then
 there's related private information which is part
 of the resource request history.  How much of this
 is being considered in the data format?

- Incremental updates in scope of format or not?

 If we're focusing on formats and have protocol
 out of scope, it may be necessary to determine
 if incremental escrow updates are in scope (and
 hence require us to include necessary sync data)
 or whether this is purely a protocol matter.

Many of the above issues might be clarified by
elaborating a problem statement or use cases...

Thanks,
/John


_______________________________________________
ire mailing list
ire@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ire

--B_3347000023_7755328-- From bortzmeyer@nic.fr Fri Jan 22 07:26: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 053BB3A6988 for ; Fri, 22 Jan 2010 07:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=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 835ASXKF5+es for ; Fri, 22 Jan 2010 07:26:49 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 309E13A6926 for ; Fri, 22 Jan 2010 07:26:49 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id 088301C0702; Fri, 22 Jan 2010 16:21:44 +0100 (CET) Received: from relay1.nic.fr (relay1.nic.fr [192.134.4.162]) by mx2.nic.fr (Postfix) with ESMTP id 044991C06F3; Fri, 22 Jan 2010 16:21:44 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay1.nic.fr (Postfix) with ESMTP id ECC40A1D9AF; Fri, 22 Jan 2010 16:21:43 +0100 (CET) Date: Fri, 22 Jan 2010 16:21:43 +0100 From: Stephane Bortzmeyer To: John Curran Message-ID: <20100122152143.GA23816@nic.fr> References: <20100122103317.GA15831@nic.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 5.0.3 X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Cc: "ire@ietf.org" Subject: Re: [ire] Protocol or format? 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, 22 Jan 2010 15:26:50 -0000 On Fri, Jan 22, 2010 at 09:37:18AM -0500, John Curran wrote a message of 47 lines which said: > - Public Internet resource registry data, or also private/NDA data > and/or metadata? Certainly private data also. Use case: AFNIC does not, by default, distribute personal data of .FR registrants who are physical persons. But we have this data and a real escrow of course needs it (otherwise it would not be possible to restart the registry.) From jgalvin@afilias.info Fri Jan 22 07:29: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 CC59D3A693B for ; Fri, 22 Jan 2010 07:29:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.832 X-Spam-Level: X-Spam-Status: No, score=-5.832 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, 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 Eb9PWVMY8CRY for ; Fri, 22 Jan 2010 07:29:03 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 0DCF13A6882 for ; Fri, 22 Jan 2010 07:29:03 -0800 (PST) Date: Fri, 22 Jan 2010 10:29:23 -0500 From: James M Galvin To: ire@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Authenticated: True Subject: Re: [ire] Protocol or format? 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, 22 Jan 2010 15:29:03 -0000 I agree with you that these are important topics for discussion. Jim -- On January 22, 2010 9:31:37 AM -0500 James Gould=20 wrote regarding Re: [ire] Protocol or format? -- > Yes, I agree that the data comes first (what and how much). The > format of the data is also important to ensure that software can be > written that can easily process any escrow data deposited. The > transport is less of an issue, but it would be good if there was an > agreed upon secure transport for the escrow data. Are the files > encrypted, are they unencrypted and passed across an encrypted > transport, or a combination. My concern is related to the encryption > of the data itself to again ensure that software can easily process > escrowed data in a standard and =E2=80=9Csecure=E2=80=9D manor. From jgalvin@afilias.info Fri Jan 22 07:31:32 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 0F2093A6990 for ; Fri, 22 Jan 2010 07:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.94 X-Spam-Level: X-Spam-Status: No, score=-5.94 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, 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 A8ufPVLRNO9s for ; Fri, 22 Jan 2010 07:31:31 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id F31933A681D for ; Fri, 22 Jan 2010 07:31:30 -0800 (PST) Date: Fri, 22 Jan 2010 10:31:51 -0500 From: James M Galvin To: John Curran , ire@ietf.org Message-ID: <5EDD0B6936ED4ACCE1AA6D21@James-Galvin.local> In-Reply-To: References: <20100122103317.GA15831@nic.fr> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Authenticated: True Subject: Re: [ire] Protocol or format? 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, 22 Jan 2010 15:31:32 -0000 Good questions John. I think they should be in scope for the working group but we'll have to see what comes from the BOF discussion. Jim -- On January 22, 2010 9:37:18 AM -0500 John Curran wrote regarding Re: [ire] Protocol or format? -- > Some IRE Charter Questions - > > Scope > > - Internet resource registry data in general, or > just registry data needed for escrow purposes? > > i.e. Presently the RIR's publish 'daily files', > containing summaries of number resource changes > for each day, these files are used for statistics > and for informing the operational/security community > about resource allocations. The RIR's have worked > to bring about more commonality on publication > format; would this also be a potential use for > the format being considered by the working group, > or it is specifically targeted at escrow purposes? > > - Public Internet resource registry data, or also > private/NDA data and/or metadata? > > While we all know what shows up in WHOIS, there's > actually quite a bit of data behind the scenes > regarding allocation and change history which is > not visible but still important to have, and then > there's related private information which is part > of the resource request history. How much of this > is being considered in the data format? > > - Incremental updates in scope of format or not? > > If we're focusing on formats and have protocol > out of scope, it may be necessary to determine > if incremental escrow updates are in scope (and > hence require us to include necessary sync data) > or whether this is purely a protocol matter. > > Many of the above issues might be clarified by > elaborating a problem statement or use cases... > > Thanks, > /John > > > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire From Ed.Lewis@neustar.biz Fri Jan 22 11:11:05 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 95D7F3A6AA3 for ; Fri, 22 Jan 2010 11:11:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.909, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 wSFxvDUAggp3 for ; Fri, 22 Jan 2010 11:11:04 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id BD6C03A6AAE for ; Fri, 22 Jan 2010 11:11:01 -0800 (PST) Received: from [10.31.200.180] (mail.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0MJAuKc020632; Fri, 22 Jan 2010 14:10:56 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: Date: Fri, 22 Jan 2010 13:59:59 -0500 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] BoF mode 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, 22 Jan 2010 19:11:05 -0000 Reading over the discussion from yesterday... The mysterious "we" that started the ball rolling are Francisco Arias, Jim Galvin and myself. As we don't work geographically near each other, the short term organizing has been a little disjoint. Hopefully we have a physical BoF in Anaheim, Jim and I will be the chairs. The comments about the word "protocol" and the questions about scope are good ones, and somewhat anticipated. "Protocol" has a wide range of meanings although in the IETF we tend to think of a protocol as the way you send data back and forth. When the list announcement was made I did hesitate to leave protocol in because I know most will think of something over a transport. But I left it in because of the broader definition (a way to do things) - and that in the past there ASN.1 was an OSI Presentation Layer "protocol." And, I did figure that the use of the word there would grab some attention. This isn't to quibble over it, just to mention that yeah, I knew you'd think that... As far as the scope questions, this is what we want to cover. In coming days there will be more put to the list by Francisco in the form of an internet-draft. The hope is that we can define a broadest reasonable audience for the work. I can't promise all comers will have needs addressed, but we want to start wider so we won't go back later and think we purposely excluded someone. One regret with PROVREG (the WG that reviewed EPP) is that there are many who said "if we know how this would grow, we'd have participated and lobbyied for other changes." I'm sure IRE won't be the end-all in escrow but we want to maximize it's applicability. Is it reasonable to use an escrow dump of an RIR to let a domain name registry provide a temporary backup facility? Dunno. Well, we are in BoF mode now. We want to shape the work and present to the IETF AD (Applications Area) an proposal for a WG (if we get there). That's the next "process" target. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From paul.hoffman@vpnc.org Mon Jan 25 17:40: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 827E43A684D for ; Mon, 25 Jan 2010 17:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.226 X-Spam-Level: X-Spam-Status: No, score=-104.226 tagged_above=-999 required=5 tests=[AWL=1.820, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 apwxZG9bq56z for ; Mon, 25 Jan 2010 17:40:05 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 21D283A67D8 for ; Mon, 25 Jan 2010 17:40:02 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0Q1e8MF028147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Jan 2010 18:40:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 25 Jan 2010 17:40:06 -0800 To: ire@ietf.org From: Internet-Drafts@ietf.org (by way of Paul Hoffman) Content-Type: text/plain; charset="us-ascii" Subject: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt 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, 26 Jan 2010 01:40:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internet Domain Registry Data Escrow specification Author(s) : F. Arias Filename : draft-arias-registry-data-escrow-00.txt Pages : 24 Date : 2010-01-25 This document specifies the format and contents of Data Escrow deposits for Domain Registries. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-arias-registry-data-escrow-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From paul.hoffman@vpnc.org Mon Jan 25 17:56: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 9B57A3A67D8 for ; Mon, 25 Jan 2010 17:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.046 X-Spam-Level: X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 Zy7E5mV5dGkj for ; Mon, 25 Jan 2010 17:56:28 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id B08133A67A7 for ; Mon, 25 Jan 2010 17:56:28 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0Q1iU6h028499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Jan 2010 18:44:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 25 Jan 2010 17:44:28 -0800 To: ire@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt 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, 26 Jan 2010 01:56:29 -0000 I'm now very confused about this BoF. The draft that Ed promised had been published. The draft describes a format that is unlike almost any published by the IETF (CSV, metadata both in the file name and in the first line of the file, and so on). The draft also points to , which looks like a nearly-done agreement that embodies this work. Why is the IRE work being proposed to be done in the IETF at all if ICANN has pretty much agreed on the format in advance, and is choosing to use a format that would probably not come out of the IETF if it had been designed here? Shouldn't this just be ICANN work? --Paul Hoffman, Director --VPN Consortium From francisco.arias@icann.org Mon Jan 25 18:19: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 EF1CE3A676A for ; Mon, 25 Jan 2010 18:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 JlQZVXhsZwok for ; Mon, 25 Jan 2010 18:18:59 -0800 (PST) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by core3.amsl.com (Postfix) with ESMTP id C3B6F3A67D8 for ; Mon, 25 Jan 2010 18:18:59 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Mon, 25 Jan 2010 18:19:07 -0800 From: Francisco Arias To: Paul Hoffman , "ire@ietf.org" Date: Mon, 25 Jan 2010 18:19:04 -0800 Thread-Topic: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt Thread-Index: AcqeKtsiINk3ACRvT6uI2EO672z8XAAAxMKY 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: multipart/alternative; boundary="_000_C78391181FA4franciscoariasicannorg_" MIME-Version: 1.0 Subject: Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt 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, 26 Jan 2010 02:19:02 -0000 --_000_C78391181FA4franciscoariasicannorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Paul, Sorry for the misunderstanding. I was going to send a message explaining it= but you got ahead of me with the announcement. The document being referred in the I-D (which is also a draft in ICANN) is = just what was used as a basis. A community worked on the ICANN document and= then asked for it to be taken to IETF to better be developed here. Even though that I can not speak for ICANN, it there were a Registry Data E= scrow RFC, I think ICANN would be very happy to use it instead of whatever = is now there; just as it is done with other IETF standards for DNS, EPP, WH= OIS, etc. In other words, this work once began in the ICANN community, but being a te= chnical work more than policy, some of us thought it will be better done in= side the IETF where a more broader technical community could participate in= the effort and give a better technical result. In the question of CSV, I should say I think it doesn't have to be CSV. If = the group believes XML or something else is better for the task, so be it. = Currently it is just what is there. Regards, __ Francisco On 1/25/10 5:44 PM, "Paul Hoffman" wrote: I'm now very confused about this BoF. The draft that Ed promised had been p= ublished. The draft describes a format that is unlike almost any published = by the IETF (CSV, metadata both in the file name and in the first line of t= he file, and so on). The draft also points to , which looks like = a nearly-done agreement that embodies this work. Why is the IRE work being proposed to be done in the IETF at all if ICANN h= as pretty much agreed on the format in advance, and is choosing to use a fo= rmat that would probably not come out of the IETF if it had been designed h= ere? Shouldn't this just be ICANN work? --Paul Hoffman, Director --VPN Consortium _______________________________________________ ire mailing list ire@ietf.org https://www.ietf.org/mailman/listinfo/ire --_000_C78391181FA4franciscoariasicannorg_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt Hi Paul,

Sorry for the misunderstanding. I was going to send a message explaining it= but you got ahead of me with the announcement.

The document being referred in the I-D (which is also a draft in ICANN) is = just what was used as a basis. A community worked on the ICANN document and= then asked for it to be taken to IETF to better be developed here.

Even though that I can not speak for ICANN, it there were a Registry Data E= scrow RFC, I think ICANN would be very happy to use it instead of whatever = is now there; just as it is done with other IETF standards for DNS, EPP, WH= OIS, etc.

In other words, this work once began in the ICANN community, but being a te= chnical work more than policy, some of us thought it will be better done in= side the IETF where a more broader technical community could participate in= the effort and give a better technical result.

In the question of CSV, I should say I think it doesn't have to be CSV. If = the group believes XML or something else is better for the task, so be it. = Currently it is just what is there.

Regards,

__
Francisco




On 1/25/10 5:44 PM, "Paul Hoffman" <paul.hoffman@vpnc.org> wrote:

I'm now very confused about this BoF. The draft that Ed promised had bee= n published. The draft describes a format that is unlike almost any publish= ed by the IETF (CSV, metadata both in the file name and in the first line o= f the file, and so on). The draft also points to <h= ttp://www.icann.org/en/topics/new-gtlds/draft-agreement-specs-clean-04oct09= -en.pdf>, which looks like a nearly-done agreement that embodies thi= s work.

Why is the IRE work being proposed to be done in the IETF at all if ICANN h= as pretty much agreed on the format in advance, and is choosing to use a fo= rmat that would probably not come out of the IETF if it had been designed h= ere? Shouldn't this just be ICANN work?

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
ire mailing list
ire@ietf.org
https://www.ietf.org/= mailman/listinfo/ire

--_000_C78391181FA4franciscoariasicannorg_-- From paul.hoffman@vpnc.org Mon Jan 25 18:27: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 F0CF73A676A for ; Mon, 25 Jan 2010 18:27:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.981 X-Spam-Level: X-Spam-Status: No, score=-5.981 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock10=0.13] 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 lLc2t8ThmX+K for ; Mon, 25 Jan 2010 18:27:37 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 2E1A23A659B for ; Mon, 25 Jan 2010 18:27:37 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0Q2RMdr031254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Jan 2010 19:27:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 25 Jan 2010 18:27:21 -0800 To: Francisco Arias , "ire@ietf.org" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt 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, 26 Jan 2010 02:27:38 -0000 At 6:19 PM -0800 1/25/10, Francisco Arias wrote: >Sorry for the misunderstanding. I was going to send a message explaining it but you got ahead of me with the announcement. Heck, I even waited a few hours after you posted the draft. :-) >The document being referred in the I-D (which is also a draft in ICANN) is just what was used as a basis. A community worked on the ICANN document and then asked for it to be taken to IETF to better be developed here. > >Even though that I can not speak for ICANN, it there were a Registry Data Escrow RFC, I think ICANN would be very happy to use it instead of whatever is now there; just as it is done with other IETF standards for DNS, EPP, WHOIS, etc. > >In other words, this work once began in the ICANN community, but being a technical work more than policy, some of us thought it will be better done inside the IETF where a more broader technical community could participate in the effort and give a better technical result. Really? They will wait for the new gTLD agreements until the IETF comes up with a standard for this format? That seems either very unlikely or very unwise. Also, the referred-to draft agreement says that the format is being developed by ICANN and registry technical teams; is there any indication of actual buy-in to waiting for the IETF to do the work? >In the question of CSV, I should say I think it doesn't have to be CSV. CSV is fine if you don't mind horrible quoting problems and more edge cases than you can imagine. >If the group believes XML or something else is better for the task, so be it. Currently it is just what is there. There will probably be at least four different formats proposed. --Paul Hoffman, Director --VPN Consortium From francisco.arias@icann.org Mon Jan 25 18:57:38 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 89CB03A6810 for ; Mon, 25 Jan 2010 18:57:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock10=0.13] 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 Jm8bWfNIA8BE for ; Mon, 25 Jan 2010 18:57:37 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id C73D83A676A for ; Mon, 25 Jan 2010 18:57:37 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Mon, 25 Jan 2010 18:57:46 -0800 From: Francisco Arias To: Paul Hoffman , "ire@ietf.org" Date: Mon, 25 Jan 2010 18:57:42 -0800 Thread-Topic: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt Thread-Index: AcqeLyXx76IzPErKSmSvHCvo8qEXKgABC3fq 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] I-D Action:draft-arias-registry-data-escrow-00.txt 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, 26 Jan 2010 02:57:38 -0000 On 1/25/10 6:27 PM, "Paul Hoffman" wrote: >> The document being referred in the I-D (which is also a draft in ICANN) = is >> just what was used as a basis. A community worked on the ICANN document = and >> then asked for it to be taken to IETF to better be developed here. >>=20 >> Even though that I can not speak for ICANN, it there were a Registry Dat= a >> Escrow RFC, I think ICANN would be very happy to use it instead of whate= ver >> is now there; just as it is done with other IETF standards for DNS, EPP, >> WHOIS, etc. >>=20 >> In other words, this work once began in the ICANN community, but being a >> technical work more than policy, some of us thought it will be better do= ne >> inside the IETF where a more broader technical community could participa= te in >> the effort and give a better technical result. >=20 > Really? They will wait for the new gTLD agreements until the IETF comes u= p > with a standard for this format? That seems either very unlikely or very > unwise. Also, the referred-to draft agreement says that the format is bei= ng > developed by ICANN and registry technical teams; is there any indication = of > actual buy-in to waiting for the IETF to do the work? I never said they will wait, and I think they won't. I think a Registry Dat= a Escrow (RyDE) spec as RFC would be used once it is available. Currently there are other non-technical issues that need to be solved prior to the launch of new gTLDs. I don't know when they are going to be solved. Also there are other things that would need to happen after the launch (reception of applications, evaluation, etc.) before there is any Agreement signed. Maybe we could have the RFC before there is any Agreement signed. __=20 Francisco From jgalvin@afilias.info Tue Jan 26 04:52:27 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 1DAED3A6962 for ; Tue, 26 Jan 2010 04:52:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnOsft9P7nRH for ; Tue, 26 Jan 2010 04:52:26 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id F38883A6948 for ; Tue, 26 Jan 2010 04:52:25 -0800 (PST) Date: Tue, 26 Jan 2010 07:53:03 -0500 From: James M Galvin To: Paul Hoffman , ire@ietf.org Message-ID: <688C430567AA1A1DD7C4031F@James-Galvin.local> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Authenticated: True Subject: Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt 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, 26 Jan 2010 12:52:27 -0000 Speaking as co-chair of the BOF: -- On January 25, 2010 5:44:28 PM -0800 Paul Hoffman wrote regarding Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt -- > I'm now very confused about this BoF. The draft that Ed promised had > been published. The draft describes a format that is unlike almost > any published by the IETF (CSV, metadata both in the file name and in > the first line of the file, and so on). The draft also points to > -04oct09-en.pdf>, which looks like a nearly-done agreement that > embodies this work. As is common with many (most?) BOFs these days in the IETF, the draft is an individual submission being offered as a starting point for this work, if the IETF adopts it of course. > Why is the IRE work being proposed to be done in the IETF at all if > ICANN has pretty much agreed on the format in advance, and is > choosing to use a format that would probably not come out of the IETF > if it had been designed here? For many of the same reasons that any work is brought to the IETF. Here's a few that come to my mind. While ICANN is not purely a policy body I think it is fair to say that it leans on the policy side. This work is purely technical. While it is true that many of those who would be most directly affected by this work do participate in ICANN's work, this work has the potential to be useful outside of just registries. In addition, given the technical nature of this work and the tendency towards policy issues on the ICANN side, more of the necessary technical participants will be present in the IETF. There is a broader base of expertise present in the IETF that this work would benefit from, e.g., security review. You pointed out another example above: the format chosen. People tend to work with what they know. There are more "format experts" in the IETF and thus this work is likely to find a better choice in this forum. Finally, this is not the first time ICANN has looked to the IETF for technical expertise. You do remember EPP and CRISP? > Shouldn't this just be ICANN work? ICANN will set a policy that adopts this work, if the IETF agrees to do the work. This is as it should be, in my opinion of course. Jim From jgalvin@afilias.info Tue Jan 26 05:00:58 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 9B5E63A695E for ; Tue, 26 Jan 2010 05:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.2 X-Spam-Level: X-Spam-Status: No, score=-6.2 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock10=0.13] 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 WtEcrDfkXRHf for ; Tue, 26 Jan 2010 05:00:57 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 08EEA3A6947 for ; Tue, 26 Jan 2010 05:00:56 -0800 (PST) Date: Tue, 26 Jan 2010 08:01:33 -0500 From: James M Galvin To: Paul Hoffman , Francisco Arias , ire@ietf.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Authenticated: True Subject: Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt 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, 26 Jan 2010 13:00:58 -0000 Speaking as co-chair of the BOF: -- On January 25, 2010 6:27:21 PM -0800 Paul Hoffman wrote regarding Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt -- > At 6:19 PM -0800 1/25/10, Francisco Arias wrote: > > In other words, this work once began in the ICANN community, but > > being a technical work more than policy, some of us thought it will > > be better done inside the IETF where a more broader technical > > community could participate in the effort and give a better > > technical result. > > Really? They will wait for the new gTLD agreements until the IETF > comes up with a standard for this format? That seems either very > unlikely or very unwise. Also, the referred-to draft agreement says > that the format is being developed by ICANN and registry technical > teams; is there any indication of actual buy-in to waiting for the > IETF to do the work? Sorry for the confusion Paul. It was decided to move this along in the IETF less than a week ago and we've had the BOF request deadline right in front of us. So, while Francisco did a great job getting the document into an internet draft format and published, there are a few rough edges. ICANN is going to do what ICANN is going to do, just as the IETF is going to do what the IETF is going to do. If ICANN moves forward without this work being completed, that probably means they will just write their contracts the same way they have been for years. When the IETF is done then they'll revise their contracts. Other options are possible, I don't know nor do I control what ICANN will do, but ICANN's choice should not concern the IETF. Certainly the intent is for the IETF to adopt this work and then ICANN will adopt the completed and published specification, as they have in the past with other specification, just as any other organization might do. This is the most we can ask for right now. Jim From paul.hoffman@vpnc.org Tue Jan 26 08:33:31 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 41F243A681B for ; Tue, 26 Jan 2010 08:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.033 X-Spam-Level: X-Spam-Status: No, score=-6.033 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 p76J5bD41NOn for ; Tue, 26 Jan 2010 08:33:30 -0800 (PST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 7F67B3A67B6 for ; Tue, 26 Jan 2010 08:33:30 -0800 (PST) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0QGWv8t084222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 09:32:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 26 Jan 2010 08:32:55 -0800 To: James M Galvin , Francisco Arias , ire@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt 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, 26 Jan 2010 16:33:31 -0000 At 8:01 AM -0500 1/26/10, James M Galvin wrote: >When the IETF is done then they'll revise their contracts. That works for me. It also sets a better expectation for what the value of the IETF work might be. >Other options are possible, I don't know nor do I control what ICANN will do, but ICANN's choice should not concern the IETF. Of course it should. If ICANN said "we will write our contracts to keep our current format for ten years, then see if there is an IETF has a better idea", that would help people decide whether or not to participate. Similarly, if ICANN said "we really hope that whatever comes out of the IETF is upward compatible from what we create", that also has a huge effect on who would want to participate. >Certainly the intent is for the IETF to adopt this work and then ICANN will adopt the completed and published specification, as they have in the past with other specification, just as any other organization might do. This is the most we can ask for right now. Fully agree. --Paul Hoffman, Director --VPN Consortium From jgalvin@afilias.info Tue Jan 26 08:51:15 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 F08ED3A686C for ; Tue, 26 Jan 2010 08:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.233 X-Spam-Level: X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, 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 xTcVwFJasxEq for ; Tue, 26 Jan 2010 08:51:15 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 2A4923A67F4 for ; Tue, 26 Jan 2010 08:51:14 -0800 (PST) Date: Tue, 26 Jan 2010 11:51:51 -0500 From: James M Galvin To: Paul Hoffman , Francisco Arias , ire@ietf.org Message-ID: <8805FDBF9421BABA347B2F94@James-Galvin.local> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Authenticated: True Subject: Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt 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, 26 Jan 2010 16:51:16 -0000 -- On January 26, 2010 8:32:55 AM -0800 Paul Hoffman wrote regarding Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt -- > > Other options are possible, I don't know nor do I control what > > ICANN will do, but ICANN's choice should not concern the IETF. > > Of course it should. If ICANN said "we will write our contracts to > keep our current format for ten years, then see if there is an IETF > has a better idea", that would help people decide whether or not to > participate. Similarly, if ICANN said "we really hope that whatever > comes out of the IETF is upward compatible from what we create", that > also has a huge effect on who would want to participate. Fair enough. We don't work in a vacuum and neither should they. I'm not expecting any sort of formal statement from ICANN but it is useful to note that ICANN reached out to make this BOF happen and promote interest and development in the IETF. Given the expected timing of TLD activities in ICANN, which you mentioned early in this thread, I think it's safe to say that adoption of this work and progress on a specification sooner rather than later would be ideal. As far as "upwardly" compatible is concerned, my expectation is that those who have to implement this are going to be present in the discussion and that detail will not get lost. Jim From jaap@bartok.nlnetlabs.nl Tue Jan 26 09:17:04 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 6E7F93A688C for ; Tue, 26 Jan 2010 09:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O9n+qvoqt+X for ; Tue, 26 Jan 2010 09:17:03 -0800 (PST) Received: from bartok.nlnetlabs.nl (bartok.nlnetlabs.nl [IPv6:2001:7b8:206:1:216:76ff:feb8:3c02]) by core3.amsl.com (Postfix) with ESMTP id 19A943A67C0 for ; Tue, 26 Jan 2010 09:17:00 -0800 (PST) Received: from bartok.nlnetlabs.nl (localhost [127.0.0.1]) by bartok.nlnetlabs.nl (8.14.3/8.14.3) with ESMTP id o0QHH6eZ081137 for ; Tue, 26 Jan 2010 18:17:06 +0100 (CET) (envelope-from jaap@bartok.nlnetlabs.nl) Message-Id: <201001261717.o0QHH6eZ081137@bartok.nlnetlabs.nl> To: ire@ietf.org In-reply-to: <8805FDBF9421BABA347B2F94@James-Galvin.local> References: <8805FDBF9421BABA347B2F94@James-Galvin.local> Comments: In-reply-to James M Galvin message dated "Tue, 26 Jan 2010 11:51:51 -0500." Date: Tue, 26 Jan 2010 18:17:06 +0100 From: Jaap Akkerhuis X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (bartok.nlnetlabs.nl [127.0.0.1]); Tue, 26 Jan 2010 18:17:06 +0100 (CET) Subject: Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt 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, 26 Jan 2010 17:17:04 -0000 Jim Galvin: As far as "upwardly" compatible is concerned, my expectation is that those who have to implement this are going to be present in the discussion and that detail will not get lost. Note that there are already folks that have implemented escrow protocols on their own (not in relation with ICANN). Some (European) registries do have years of experience dealing with data in escrow. It would be benificial to have them in the discussion as well. jaap From Ed.Lewis@neustar.biz Tue Jan 26 09:22:19 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 6B1643A694F for ; Tue, 26 Jan 2010 09:22:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.397 X-Spam-Level: X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[AWL=1.202, 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 Hyl0dP5kErOY for ; Tue, 26 Jan 2010 09:22:18 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id 279093A6918 for ; Tue, 26 Jan 2010 09:22:18 -0800 (PST) Received: from [10.31.200.236] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0QHMLRi079166; Tue, 26 Jan 2010 12:22:22 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 26 Jan 2010 12:22:20 -0500 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: Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt 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, 26 Jan 2010 17:22:19 -0000 At 17:44 -0800 1/25/10, Paul Hoffman wrote: >Shouldn't this just be ICANN work? The reason I am willing to participate in this is because the underlying technical work benefits from the experiences from a wider audience than ICANN provides and can also turn around an benefit a wider audience than ICANN provides. This despite the fact that ICANN is raising the concern. In the TLD registry world, there is no alternative to the IETF when it comes to being an inclusive discussion forum for registration (technical) activity. We have ICANN, but that only covers a few TLDs (few if you count delegations from the IANA root zone). We have CENTR, APTLD, and LACTLD as other organizations that I can think of for discussion, and only one has a technical list open (only) to it's members. Expanding further, there RIRs, routing registries, etc., that have may or may not have coordination fora. Consider it an accident of history that the initial draft is rooted in the ICANN world. This accident is not looking to be rubber stamped by the IETF. The goal of the BoF is to first set goals for a WG. Our idea is that the goals of the WG was to define a standard for data escrow that could then be fed back to ICANN. Remember that we are still in BoF mode now, setting expectations. At 18:17 +0100 1/26/10, Jaap Akkerhuis wrote: >Note that there are already folks that have implemented escrow >protocols on their own (not in relation with ICANN). Some (European) >registries do have years of experience dealing with data in escrow. >It would be beneficial to have them in the discussion as well. And that's just the kind of experience the BoF wants to draw into the discussion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From jgalvin@afilias.info Tue Jan 26 09:23:54 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 617EB3A6817 for ; Tue, 26 Jan 2010 09:23:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.243 X-Spam-Level: X-Spam-Status: No, score=-6.243 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, 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 MLVN2sfLdtrK for ; Tue, 26 Jan 2010 09:23:53 -0800 (PST) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 8AE983A67CC for ; Tue, 26 Jan 2010 09:23:53 -0800 (PST) Date: Tue, 26 Jan 2010 12:24:32 -0500 From: James M Galvin To: Jaap Akkerhuis , ire@ietf.org Message-ID: <94493A3610238845F0166CBC@James-Galvin.local> In-Reply-To: <201001261717.o0QHH6eZ081137@bartok.nlnetlabs.nl> References: <8805FDBF9421BABA347B2F94@James-Galvin.local> <201001261717.o0QHH6eZ081137@bartok.nlnetlabs.nl> X-Mailer: Mulberry/4.0.8 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Authenticated: True Subject: Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt 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, 26 Jan 2010 17:23:54 -0000 Please do forward the BOF announcement on to whoever should know about it. We certainly want to include everyone we can. Jim co-chair -- On January 26, 2010 6:17:06 PM +0100 Jaap Akkerhuis wrote regarding Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt -- > > Jim Galvin: > As far as "upwardly" compatible is concerned, my expectation > is that those who have to implement this are going to be present > in the discussion and that detail will not get lost. > > Note that there are already folks that have implemented escrow > protocols on their own (not in relation with ICANN). Some (European) > registries do have years of experience dealing with data in escrow. > It would be benificial to have them in the discussion as well. > > jaap > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire From francisco.arias@icann.org Tue Jan 26 15:19: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 5E7523A68B7 for ; Tue, 26 Jan 2010 15:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 o7lMOIkx6fFg for ; Tue, 26 Jan 2010 15:19:27 -0800 (PST) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by core3.amsl.com (Postfix) with ESMTP id B53033A67F8 for ; Tue, 26 Jan 2010 15:19:27 -0800 (PST) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Tue, 26 Jan 2010 15:19:39 -0800 From: Francisco Arias To: Jaap Akkerhuis , "ire@ietf.org" Date: Tue, 26 Jan 2010 15:19:38 -0800 Thread-Topic: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt Thread-Index: Acqeq3aVJ1AI2qcMSz6lyaZXhz1xbAAMpD3b Message-ID: In-Reply-To: <201001261717.o0QHH6eZ081137@bartok.nlnetlabs.nl> 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] I-D Action:draft-arias-registry-data-escrow-00.txt 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, 26 Jan 2010 23:19:28 -0000 On 1/26/10 9:17 AM, "Jaap Akkerhuis" wrote: > > Note that there are already folks that have implemented escrow > protocols on their own (not in relation with ICANN). Some (European) > registries do have years of experience dealing with data in escrow. > It would be benificial to have them in the discussion as well. I think there are already a few people from ccTLDs in this list as the message got to the four regional ccTLD organizations (AfTLD, APTLD, CENTR and LACTLD). I don't know if it got to the RIR's, Registrars and others who may also be interested? __=20 Francisco From bortzmeyer@nic.fr Wed Jan 27 07:35: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 0F20F3A693D for ; Wed, 27 Jan 2010 07:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=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 fdEGbQ3hRg6D for ; Wed, 27 Jan 2010 07:35:16 -0800 (PST) Received: from mx2.nic.fr (mx2.nic.fr [192.134.4.11]) by core3.amsl.com (Postfix) with ESMTP id 6C1323A6840 for ; Wed, 27 Jan 2010 07:35:16 -0800 (PST) Received: from mx2.nic.fr (localhost [127.0.0.1]) by mx2.nic.fr (Postfix) with SMTP id F06341C022A for ; Wed, 27 Jan 2010 16:30:29 +0100 (CET) Received: from relay2.nic.fr (relay2.nic.fr [192.134.4.163]) by mx2.nic.fr (Postfix) with ESMTP id E266D1C0229 for ; Wed, 27 Jan 2010 16:30:29 +0100 (CET) Received: from bortzmeyer.nic.fr (batilda.nic.fr [192.134.4.69]) by relay2.nic.fr (Postfix) with ESMTP id E00377B0034 for ; Wed, 27 Jan 2010 16:30:29 +0100 (CET) Date: Wed, 27 Jan 2010 16:30:29 +0100 From: Stephane Bortzmeyer To: ire@ietf.org Message-ID: <20100127153029.GA17938@nic.fr> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Debian GNU/Linux 5.0.3 X-Kernel: Linux 2.6.26-2-686 i686 Organization: NIC France X-URL: http://www.nic.fr/ User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt 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, 27 Jan 2010 15:35:18 -0000 On Mon, Jan 25, 2010 at 05:40:06PM -0800, by way of Paul Hoffman wrote a message of 36 lines which said: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Internet Domain Registry Data Escrow specification >From the discussion that followed, I understand that it is not a real proposal, just an example of what a standard could look like, in order to sparkle the discussion. If so, thanks, it is an useful document. IMHO, it is also a good example of what we should NOT do in the future possible Working Group. 1) The biggest problem is that it is not policy-independant. A lot of policy choices are cast in stone in this document. (Personal opinion: even if it's limited to ICANN's TLD, I find incredible the level of micro-management exercised by ICANN and the little freedom it leaves to the registries.) A few examples: the mandatory inclusion of registrar data (even billing data), the status codes from RFC 5731, the obligation to escrow the ACE encoding of an IDN instead of the real Unicode name, the long lists of mandatory attributes in section 5.1 (what if there is no expiration in the registry?), the lack of some very important attributes in 5.2 (for instance, for a contact, whether he is a physical person - and therefore entitled to the data privacy provisions - or not), etc. 2) A variant of the previous problem: it is intended only for one class of objects, domain names. John Curran indicated here that he could be interested in a format for IP registries. May be something more like EPP and IRIS (separating the format and the definition of the classes of objects) would be a good idea. As said already here, we should discuss the objects first and the format after. 3) The draft goes in very low-level details, even the filename convention, which is not necessary for interoperability. IETF is about formats and protocols, not procedures. Similar issue with things like compression or encryption. 4) There is a discussion of Full vs. Incremental deposits. Before deciding on a format for incremental deposits, we should search if they are worth it. In my opinion, for an escrow system, integrity is the most important thing and it is easier to achive with only full deposits (if we are worry about performances, we can always use a mechanism like rsync). Even if we use incremental deposits, rather than inventing a patch language, we should reuse an existing one (for instance RFC 5261 if the format is XML). 5) There is an obligation to escrow the forbidden names. But they are not always defined in extension , sometimes the rules are intensional (example: in .FR, the law - not the registry's rules - forbids registration of the names of the cities, even if intermixed with dashes so paris.fr and p-a-ris.fr and p-a-r-i-s.fr are all reserved to the mayor, something you cannot enumerate). 6) Some choices even restrict the current rules, without explanation. For instance, in the DNSSEC section, the public key is mandatory, while RFC 4310 and RFC 4641 does not force the registrant to send it to the registry. From Ed.Lewis@neustar.biz Wed Jan 27 09:20:45 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 54BCF3A6AC6 for ; Wed, 27 Jan 2010 09:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.115 X-Spam-Level: X-Spam-Status: No, score=-2.115 tagged_above=-999 required=5 tests=[AWL=0.484, 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 PdhiIJYGaTUP for ; Wed, 27 Jan 2010 09:20:44 -0800 (PST) Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by core3.amsl.com (Postfix) with ESMTP id D15773A6862 for ; Wed, 27 Jan 2010 09:20:42 -0800 (PST) Received: from [10.31.201.16] (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.3/8.14.3) with ESMTP id o0RHKspV088660; Wed, 27 Jan 2010 12:20:54 -0500 (EST) (envelope-from Ed.Lewis@neustar.biz) Mime-Version: 1.0 Message-Id: In-Reply-To: <20100127153029.GA17938@nic.fr> References: <20100127153029.GA17938@nic.fr> Date: Wed, 27 Jan 2010 12:20:52 -0500 To: Stephane Bortzmeyer From: Edward Lewis Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.67 on 10.20.30.4 Cc: ire@ietf.org Subject: Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt 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, 27 Jan 2010 17:20:45 -0000 I appreciate seeing this level of comment. This demonstrates the need for the broad external review that can be best accomplished within the IETF. It also demonstrates that we have to travel quite a distance to accomplish the goal of an escrow "protocol" (nodding that protocol here does not imply specifying a transport layer protocol). At 16:30 +0100 1/27/10, Stephane Bortzmeyer wrote: >1) The biggest problem is that it is not policy-independant. >2) A variant of the previous problem: it is intended only for one >class of objects, domain names. John Curran indicated here that he >could be interested in a format for IP registries. When I consider the work item here I ask myself, "can I imagine my current employer (an ICANN gTLD operator and a ccTLD operator) assuming the operations for my previous employer (an RIR) for a 6-month period in just a few days/weeks and then reversing the flow in a short time window? That's certainly not a general case, but it is kind of what would be desirable to achieve. >3) The draft goes in very low-level details... >4) ...deciding on a format for , ... if they are worth it. >5) There is an obligation to ... the law - ... >6) Some choices ... restrict ... current rules... As a chair my first priority is process, so in as much as my opinions agree or disagree, I'll refrain from saying now. I do want to highlight the implicit actions items Stephan has raised. 1 - Figure out how to separate data expression and policy 2 - Make this as general as possible within bounds of usefulness 3 - Target first interoperability 4 - Evaluate what's a requirement 5 - Evaluate this with the realization of the environments 6 - Review the specification for consistency with other specifications Etc. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 As with IPv6, the problem with the deployment of frictionless surfaces is that they're not getting traction. From hotta@jprs.co.jp Wed Jan 27 15:30:56 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 3684A3A6ACD for ; Wed, 27 Jan 2010 15:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.753 X-Spam-Level: *** X-Spam-Status: No, score=3.753 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HELO_EQ_NE_JP=1.244, HOST_EQ_JP=1.265, HOST_EQ_NE_JP=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 7uWTqMLqFBBP for ; Wed, 27 Jan 2010 15:30:55 -0800 (PST) Received: from smtp.green.ocn.ne.jp (green.ocn.ne.jp [60.37.40.150]) by core3.amsl.com (Postfix) with ESMTP id 5BAA93A67D7 for ; Wed, 27 Jan 2010 15:30:55 -0800 (PST) Received: from [127.0.0.1] (unknown [68.170.67.12]) by smtp.green.ocn.ne.jp (Postfix) with ESMTP id A517C41FB for ; Thu, 28 Jan 2010 08:31:09 +0900 (JST) Date: Thu, 28 Jan 2010 08:31:08 +0900 From: HiroHOTTA To: ire@ietf.org Sender: hotta@jprs.co.jp In-Reply-To: <201001261717.o0QHH6eZ081137@bartok.nlnetlabs.nl> References: <8805FDBF9421BABA347B2F94@James-Galvin.local> <201001261717.o0QHH6eZ081137@bartok.nlnetlabs.nl> Message-Id: <20100128082728.1B3D.2448D065@jprs.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.50.02 [ja] Subject: Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt X-BeenThere: ire@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: hotta@jprs.co.jp List-Id: "Internet Registration Escrow discussion list." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 23:30:56 -0000 On Tue, 26 Jan 2010 18:17:06 +0100 Jaap Akkerhuis wrote: > > Jim Galvin: > As far as "upwardly" compatible is concerned, my expectation > is that those who have to implement this are going to be present > in the discussion and that detail will not get lost. > > Note that there are already folks that have implemented escrow > protocols on their own (not in relation with ICANN). Some (European) > registries do have years of experience dealing with data in escrow. and .JP runs its daily regitry data escrow as well. Hiro > It would be benificial to have them in the discussion as well. > > jaap > _______________________________________________ > ire mailing list > ire@ietf.org > https://www.ietf.org/mailman/listinfo/ire From cbbrowne@ca.afilias.info Thu Jan 28 15:48:41 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 D865B3A67D7 for ; Thu, 28 Jan 2010 15:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEm8tNryWfyl for ; Thu, 28 Jan 2010 15:48:40 -0800 (PST) Received: from tor-gateway.afilias.info (tor-gateway.afilias.info [199.15.87.4]) by core3.amsl.com (Postfix) with ESMTP id 1CB2B3A67BE for ; Thu, 28 Jan 2010 15:48:39 -0800 (PST) Received: from [10.10.68.46] (helo=dba2.int.libertyrms.com ident=postfix) by tor-gateway.afilias.info with smtp (Exim 4.69) (envelope-from ) id 1Nae6J-0002g1-86; Thu, 28 Jan 2010 18:48:39 -0500 Received: by dba2.int.libertyrms.com (Postfix, from userid 1000) id 5853186C044; Thu, 28 Jan 2010 18:48:39 -0500 (EST) From: Christopher Browne To: Stephane Bortzmeyer Organization: Afilias Canada - Architecture Department References: <20100127153029.GA17938@nic.fr> Date: Thu, 28 Jan 2010 18:48:39 -0500 In-Reply-To: <20100127153029.GA17938@nic.fr> (Stephane Bortzmeyer's message of "Wed, 27 Jan 2010 16:30:29 +0100") Message-ID: <877hr1x02w.fsf@dba2.int.libertyrms.com> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: ire@ietf.org Subject: Re: [ire] I-D Action:draft-arias-registry-data-escrow-00.txt 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, 28 Jan 2010 23:48:42 -0000 Stephane Bortzmeyer writes: > On Mon, Jan 25, 2010 at 05:40:06PM -0800, > by way of Paul Hoffman wrote > a message of 36 lines which said: > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : Internet Domain Registry Data Escrow specification > > From the discussion that followed, I understand that it is not a real > proposal, just an example of what a standard could look like, in order > to sparkle the discussion. > > If so, thanks, it is an useful document. IMHO, it is also a good > example of what we should NOT do in the future possible Working Group. > > 1) The biggest problem is that it is not policy-independant. A lot of > policy choices are cast in stone in this document. (Personal opinion: > even if it's limited to ICANN's TLD, I find incredible the level of > micro-management exercised by ICANN and the little freedom it leaves > to the registries.) A few examples: the mandatory inclusion of > registrar data (even billing data), the status codes from RFC 5731, > the obligation to escrow the ACE encoding of an IDN instead of the > real Unicode name, the long lists of mandatory attributes in section > 5.1 (what if there is no expiration in the registry?), the lack of > some very important attributes in 5.2 (for instance, for a contact, > whether he is a physical person - and therefore entitled to the data > privacy provisions - or not), etc. I originally wrote a fair chunk of it, and a lot of it remains after a couple of layers of rewrites by others, so I can comment on why some of these things were suggested. Hopefully the perspective seems useful. A number of the criticisms you're pointing at it fall from using EPP-related specs as sources. - Using whatever random status codes anyone might want to use seems a bit too open-ended; - Using those from RFC 5731 as a starting point seemed pretty appropriate. The sets of attributes similarly derive from what's in the RFCs about EPP. I'll decline to quibble about which attributes are "very important" or not - the factor determining their absence is that if they weren't in a normative source such as RFC 4933 (or, I guess, 5733, now), it would have been a leap to propose adding them, so I didn't. It is quite appropriate for this group to consider adding attributes that are agreed to be important. On the provreg list, there's a relevant parallel process going on... There is discussion ongoing as to what sorts of extensions ought to be consolidated into common RFCs, as different registries frequently implement different custom extensions for one thing or another. I would think that to be a proper thing to reference - common escrowed data presumably begins with the sorts of data that are fairly universal ("included in base EPP RFCs" seems like a pretty good measure of that to me), EPP extensions being a natural way to characterize, in a normative fashion, things that are common additions. As for the ACE-versus-Unicode issue, the perspective that I came from was that it was necessary to capture the DNS data in the form in which it will be passed around by BIND and the like, and that form is, at this point, the ASCII-encoded form. This isn't the time to get into detailed debate about the handling of IDN variants and such, but that certainly is an important complication. > 3) The draft goes in very low-level details, even the filename > convention, which is not necessary for interoperability. IETF is about > formats and protocols, not procedures. Similar issue with things like > compression or encryption. I wasn't very comfortable with this portion; when discussing it with some of our operations folks, they were actually keen on putting in even more details relating to error checking, resubmission, and such. At one point, I was seeing something akin to the file version numbers of VMS or ISO9660 emerging, which seemed like *way* too much detail to go into, even if we were embracing a "procedural" perspective. That is definitely inappropriate at the IETF level. But keep in mind that the origin of the document was as a proposal of ICANN policy, and there are therefore things that could be apropos there, even though they aren't appropriate to an IETF protocol process. > 4) There is a discussion of Full vs. Incremental deposits. Before > deciding on a format for incremental deposits, we should search if > they are worth it. In my opinion, for an escrow system, integrity is > the most important thing and it is easier to achive with only full > deposits (if we are worry about performances, we can always use a > mechanism like rsync). Even if we use incremental deposits, rather > than inventing a patch language, we should reuse an existing one (for > instance RFC 5261 if the format is XML). I suspect that there is a partitioning that should be done between protocol and procedure, which might even appropriately cross organizational layers. That is, it could be appropriate to have: a) An IETF protocol describing internals of format, and b) An ICANN document that references the IETF material, which then specifies (or suggests) usage patterns. While I agree that full-versus-incremental is a performance optimization, I would be disappointed if the possible need for awareness of this was pushed out and treated as a purely out-of-band technical mechanism. It may be that recognizing "incremental aspects" at the protocol/format level will not be terribly difficult, and can ease the deployment of technical solutions. When we're at the state of trying to define the work of the working group, it's a bit early to conclude that this should certainly be left out. If I put my "have-done-escrow" hat on for the moment, I'll just comment that I've never actually used "incremental deposit" to improve performance. It hasn't seemed worthwhile. Every time hardware or networks improve, the size of registry that would need "incremental" increases. Perhaps hardware's good enough that it doesn't matter anymore. On the other hand, putting on the "I have seen precedent" hat, ICANN has described escrow processes on several occasions (two of which I examined in a fair bit of detail), and each time they have described escrow, they have included provision for incremental deposits. > 5) There is an obligation to escrow the forbidden names. But they are > not always defined in extension > , sometimes the > rules are intensional (example: in .FR, the law - not the registry's > rules - forbids registration of the names of the cities, even if > intermixed with dashes so paris.fr and p-a-ris.fr and p-a-r-i-s.fr are > all reserved to the mayor, something you cannot enumerate). There is certainly similarity in this case to the handling of IDN variants, where there are frequently the same pair of possibilities: a) The set of names restricted from registration are discretely enumerable, and a list of "reasonable" size that may be listed in detail b) The set of names restricted are not reasonably enumerable, such that all that is "reasonable" to record is a reference to the algorithm required to compute matches against the set This will surely warrant further discussion. > 6) Some choices even restrict the current rules, without > explanation. For instance, in the DNSSEC section, the public key is > mandatory, while RFC 4310 and RFC 4641 does not force the registrant > to send it to the registry. The ongoing discussion of 4310bis on ietf-provreg indicates that there is some ways to go before that all stabilizes! No doubt the "IRE draft" predates that discussion. -- output = reverse("ofni.sailifa.ac" "@" "enworbbc") Christopher Browne Database Architect Afilias Canada