From sharon.wodjenski@neustar.biz Mon Jun 3 11:07:42 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A2221F9310 for ; Mon, 3 Jun 2013 11:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rj3LD5g4PUAS for ; Mon, 3 Jun 2013 11:07:28 -0700 (PDT) Received: from neustar.com (mx2.neustar.com [156.154.25.104]) by ietfa.amsl.com (Postfix) with ESMTP id AEDC921F8CB4 for ; Mon, 3 Jun 2013 11:05:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370282618; x=1684528095; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=igXGKGb020kL4brEazmZ/48kFEU55MnTI9RfI6IwAw4=; b=Yh9JI9nD6T8BIbp4O7yf6OhiG+GkKDw3YYP2EBUogjTdNsnTD1wfz2XLdAQo6J wNanJEyd50vjCzcQkyrDxGqA== Received: from ([10.31.13.229]) by chihiron1.nc.neustar.com with ESMTP with TLS id J041123128.19093290; Mon, 03 Jun 2013 14:03:36 -0400 Received: from STNTEXHC10.cis.neustar.com (10.31.58.69) by STNTEXCHHT02.cis.neustar.com (10.31.13.229) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 3 Jun 2013 14:05:26 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.85]) by stntexhc10.cis.neustar.com ([169.254.4.66]) with mapi id 14.02.0342.003; Mon, 3 Jun 2013 14:05:21 -0400 From: "Wodjenski, Sharon" To: "'provreg@ietf.org'" Thread-Topic: launch:phase requirement for Sunrise FCFS Thread-Index: Ac5ghOmgGmHsL01wQnGL+KYsyzPB/A== Date: Mon, 3 Jun 2013 18:05:21 +0000 Message-ID: <0607A83C894B824F8778BD69F357FE580AB5A946@stntexmb13.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.31.32.86] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: jcrdEADOoYqRCbCgO71OIg== Content-Type: multipart/alternative; boundary="_000_0607A83C894B824F8778BD69F357FE580AB5A946stntexmb13cisne_" MIME-Version: 1.0 Subject: [provreg] launch:phase requirement for Sunrise FCFS X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 18:07:42 -0000 --_000_0607A83C894B824F8778BD69F357FE580AB5A946stntexmb13cisne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Everybody, We've run into a condition during development and are seeking feedback/guid= ance from the group. This case is specific to First Come, First Served Sunrises, and the delete/= update commands. When we read this in the spec: 2.2. Launch Phases The server MAY support multiple launch phases sequentially or simultaneously. The element MUST be included by the client to define the target launch phase of the command. We interpreted that to mean that the launch:phase was mandatory, and would= come in with each command in the extension. Currently, the XSD for the delete/update commands do not support the applic= ation id being optional. And of course, for a FCFS registration, the appli= cation id is not needed/used. So, the question from a client perspective is: 1. Is the launch:phase, and therefore the extension, mandatory for a= ll commands and the XSD should be modified so that the application id is op= tional (as it is in the Info command)? Or 2. For FCFS update/delete commands, the extension is not required at = all, and therefore the launch:phase is not specified. Thank you for your input on this topic. Sharon --_000_0607A83C894B824F8778BD69F357FE580AB5A946stntexmb13cisne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Everybody,

 

We’ve run into a condition during development = and are seeking feedback/guidance from the group.

 

This case is specific to First Come, First Served Su= nrises, and the delete/update commands.

 

When we read this in the spec:

 

2.2.  Launch Phases

 

   The server MAY support multiple l= aunch phases sequentially or

   simultaneously.  The <lau= nch:phase> element MUST be included by the

   client to define the target launc= h phase of the command.

 

We interpreted that to mean that the launch:phase&nb= sp; was mandatory, and would come in with each command in the extension.

 

Currently, the XSD for the delete/update commands do= not support the application id being optional.  And of course, for a = FCFS registration, the application id is not needed/used.

 

     <element name=
=3D"update" type=3D"launch:idContainerType"/>
     <element name=
=3D"delete" type=3D"launch:idContainerType"/>
 
     <!--
     Common container =
of id (identifier) element
     -->=

     <complexType n=
ame=3D"idContainerType">
       <s=
equence>
       =
  <element name=3D"phase" type=3D"launch:phaseType&q=
uot;/>
       =
  <element name=3D"applicationID" type=3D"launch:app=
licationIDType"/>
       </=
sequence>
     </complexType&=
gt;

 

So, the question from a client perspective is:<= /o:p>

 

1.     &= nbsp;  Is the launch:phase, and therefore the extens= ion, mandatory for all commands and the XSD should be modified so that the = application id is optional (as it is in the Info command)?

Or

2.     &= nbsp; For FCFS update/delete commands, the extension is n= ot required at all, and therefore the launch:phase is not specified.

 

Thank you for your input on this topic.

 

Sharon

 

--_000_0607A83C894B824F8778BD69F357FE580AB5A946stntexmb13cisne_-- From JGould@verisign.com Mon Jun 3 15:33:44 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC63721E80A2 for ; Mon, 3 Jun 2013 15:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.498 X-Spam-Level: X-Spam-Status: No, score=-4.498 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31vYmWp0JWkv for ; Mon, 3 Jun 2013 15:33:29 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id CBD2011E810F for ; Mon, 3 Jun 2013 15:26:06 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKUa0X/u3He/zF7lQufZjI/AMdtzl5f5Z5@postini.com; Mon, 03 Jun 2013 15:26:07 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r53MQ2WG021430 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Jun 2013 18:26:02 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 3 Jun 2013 18:26:01 -0400 From: "Gould, James" To: "Wodjenski, Sharon" , "'provreg@ietf.org'" Thread-Topic: [provreg] launch:phase requirement for Sunrise FCFS Thread-Index: Ac5ghOmgGmHsL01wQnGL+KYsyzPB/AAJGSwA Date: Mon, 3 Jun 2013 22:26:01 +0000 Message-ID: In-Reply-To: <0607A83C894B824F8778BD69F357FE580AB5A946@stntexmb13.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_CDD28FAA50A3Fjgouldverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 22:33:44 -0000 --_004_CDD28FAA50A3Fjgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CDD28FAA50A3Fjgouldverisigncom_" --_000_CDD28FAA50A3Fjgouldverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sharon, The intention in the draft was #2 " For FCFS update/delete commands, the ex= tension is not required at all, and therefore the launch:phase is not speci= fied.". It would be good to hear from others whether the extension should = be included for update and delete commands for launch registrations. -- JG [cid:612CB376-3E9B-4D96-B6C1-DB6A4C804448] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: , Sharon > Date: Monday, June 3, 2013 2:05 PM To: EPP Provreg > Subject: [provreg] launch:phase requirement for Sunrise FCFS Hi Everybody, We=92ve run into a condition during development and are seeking feedback/gu= idance from the group. This case is specific to First Come, First Served Sunrises, and the delete/= update commands. When we read this in the spec: 2.2. Launch Phases The server MAY support multiple launch phases sequentially or simultaneously. The element MUST be included by the client to define the target launch phase of the command. We interpreted that to mean that the launch:phase was mandatory, and would= come in with each command in the extension. Currently, the XSD for the delete/update commands do not support the applic= ation id being optional. And of course, for a FCFS registration, the appli= cation id is not needed/used. So, the question from a client perspective is: 1. Is the launch:phase, and therefore the extension, mandatory for a= ll commands and the XSD should be modified so that the application id is op= tional (as it is in the Info command)? Or 2. For FCFS update/delete commands, the extension is not required at = all, and therefore the launch:phase is not specified. Thank you for your input on this topic. Sharon --_000_CDD28FAA50A3Fjgouldverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0003BB081A3581408762D3FB61D42342@verisign.com> Content-Transfer-Encoding: quoted-printable
Sharon,<= /div>

The intention in the draft was #2 " For FCFS update/de= lete commands, the extension is not required at all, and therefore the laun= ch:phase is not specified.".  It would be good to hear from others whether the extension should be included for update an= d delete commands for launch registrations.  

-- 

 

JG

 

 

James Gould

= Principal Software Engineer

j= gould@verisign.com

=  

= 703-948-3271 (Office)

= 12061 Bluemont Way

= Reston, VA 20190

VerisignInc.com


From: <Wodjenski>, Sharon <= ;Sharon.Wodjenski@neustar.b= iz>
Date: Monday, June 3, 2013 2:05 PM<= br> To: EPP Provreg <provreg@ietf.org>
Subject: [provreg] launch:phase req= uirement for Sunrise FCFS

Hi Everybody,

 

We=92ve run into a condition during development and = are seeking feedback/guidance from the group.

 

This case is specific to First Come, First Served Su= nrises, and the delete/update commands.

 

When we read this in the spec:

 

2.2.  Launch Phases

 

   The server MAY support multiple launch= phases sequentially or

   simultaneously.  The <launch:p= hase> element MUST be included by the

   client to define the target launch pha= se of the command.

 

We interpreted that to mean that the launch:phase&nb= sp; was mandatory, and would come in with each command in the extension.

 

Currently, the XSD for the delete/update commands do= not support the application id being optional.  And of course, for a = FCFS registration, the application id is not needed/used.

 

     <element name=
=3D"update" type=3D"launch:idContainerType"/>
     <element name=
=3D"delete" type=3D"launch:idContainerType"/>
 
     <!--
     Common container =
of id (identifier) element
     -->=

     <complexType n=
ame=3D"idContainerType">
       <s=
equence>
       =
  <element name=3D"phase" type=3D"launch:phaseType&q=
uot;/>
       =
  <element name=3D"applicationID" type=3D"launch:app=
licationIDType"/>
       </=
sequence>
     </complexType&=
gt;

 

So, the question from a client perspective is:<= /o:p>

 

1. &nb= sp;      Is the launch:phase, and therefore the ex= tension, mandatory for all commands and the XSD should be modified so that = the application id is optional (as it is in the Info command)?

Or

2. &nb= sp;     For FCFS update/delete commands, the extension = is not required at all, and therefore the launch:phase is not specified.

 

Thank you for your input on this topic.

 

Sharon

 

 --_000_CDD28FAA50A3Fjgouldverisigncom_-- --_004_CDD28FAA50A3Fjgouldverisigncom_ Content-Type: image/png; name="8A7A655D-9ED0-4D38-898D-E9E8B754666E[90].png" Content-Description: 8A7A655D-9ED0-4D38-898D-E9E8B754666E[90].png Content-Disposition: inline; filename="8A7A655D-9ED0-4D38-898D-E9E8B754666E[90].png"; size=4109; creation-date="Mon, 03 Jun 2013 22:26:01 GMT"; modification-date="Mon, 03 Jun 2013 22:26:01 GMT" Content-ID: <612CB376-3E9B-4D96-B6C1-DB6A4C804448> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CDD28FAA50A3Fjgouldverisigncom_-- From sharon.wodjenski@neustar.biz Tue Jun 11 12:39:50 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08CCF21F99AB for ; Tue, 11 Jun 2013 12:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.998 X-Spam-Level: X-Spam-Status: No, score=-4.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFvk4I+u0qS4 for ; Tue, 11 Jun 2013 12:39:46 -0700 (PDT) Received: from neustar.com (smartmail.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEB221F9981 for ; Tue, 11 Jun 2013 12:39:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370979762; x=1686337386; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=Lezyfp5m8+K9RKi+t4Iaoy6Bq45eZ79pLQhv8EZYzPU=; b=Nny4psf4rNLubmHAPlTfojpup4jC4ZzXbEapSz/ySI0h4vXlSfAegCnMuGZV66 XsGm7lYtz7DgsUnVNbXyq0uQ== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.24957408; Tue, 11 Jun 2013 15:42:41 -0400 Received: from STNTEXCHCASHT04.cis.neustar.com (10.31.15.156) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 11 Jun 2013 15:39:39 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.23]) by STNTEXCHCASHT04.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Tue, 11 Jun 2013 15:39:34 -0400 From: "Wodjenski, Sharon" To: "'Gould, James'" , "'provreg@ietf.org'" Thread-Topic: [provreg] launch:phase requirement for Sunrise FCFS Thread-Index: Ac5ghOmgGmHsL01wQnGL+KYsyzPB/AAJGSwAAYxz2rA= Date: Tue, 11 Jun 2013 19:39:34 +0000 Message-ID: <0607A83C894B824F8778BD69F357FE580AB647DC@stntexmb13.cis.neustar.com> References: <0607A83C894B824F8778BD69F357FE580AB5A946@stntexmb13.cis.neustar.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.31.33.154] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: oZi8iufVtQAVjuPxFG5plg== Content-Type: multipart/related; boundary="_004_0607A83C894B824F8778BD69F357FE580AB647DCstntexmb13cisne_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 19:39:50 -0000 --_004_0607A83C894B824F8778BD69F357FE580AB647DCstntexmb13cisne_ Content-Type: multipart/alternative; boundary="_000_0607A83C894B824F8778BD69F357FE580AB647DCstntexmb13cisne_" --_000_0607A83C894B824F8778BD69F357FE580AB647DCstntexmb13cisne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As we have not received any feedback, we will take Jim's suggestion and not= require the launch extension and launch:phase for update/delete commands i= n FCFS Sunrise. Jim - could you please update the text in the next revision to clarify this= point? Thanks, Sharon From: Gould, James [mailto:JGould@verisign.com] Sent: Monday, June 03, 2013 6:26 PM To: Wodjenski, Sharon; 'provreg@ietf.org' Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS Sharon, The intention in the draft was #2 " For FCFS update/delete commands, the ex= tension is not required at all, and therefore the launch:phase is not speci= fied.". It would be good to hear from others whether the extension should = be included for update and delete commands for launch registrations. -- JG [cid:image001.png@01CE66B9.DF555EE0] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: , Sharon > Date: Monday, June 3, 2013 2:05 PM To: EPP Provreg > Subject: [provreg] launch:phase requirement for Sunrise FCFS Hi Everybody, We've run into a condition during development and are seeking feedback/guid= ance from the group. This case is specific to First Come, First Served Sunrises, and the delete/= update commands. When we read this in the spec: 2.2. Launch Phases The server MAY support multiple launch phases sequentially or simultaneously. The element MUST be included by the client to define the target launch phase of the command. We interpreted that to mean that the launch:phase was mandatory, and would= come in with each command in the extension. Currently, the XSD for the delete/update commands do not support the applic= ation id being optional. And of course, for a FCFS registration, the appli= cation id is not needed/used. So, the question from a client perspective is: 1. Is the launch:phase, and therefore the extension, mandatory for a= ll commands and the XSD should be modified so that the application id is op= tional (as it is in the Info command)? Or 2. For FCFS update/delete commands, the extension is not required at = all, and therefore the launch:phase is not specified. Thank you for your input on this topic. Sharon --_000_0607A83C894B824F8778BD69F357FE580AB647DCstntexmb13cisne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As we have not receive= d any feedback, we will take Jim’s suggestion and not require the lau= nch extension and launch:phase for update/delete commands in FCFS Sunrise.<= o:p>

 

Jim – could you = please update the text in the next revision to clarify this point?

 

Thanks,

 

Sharon

 

From: Gould, J= ames [mailto:JGould@verisign.com]
Sent: Monday, June 03, 2013 6:26 PM
To: Wodjenski, Sharon; 'provreg@ietf.org'
Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS

 

Sharon,=

&n= bsp;

The intention in the dra= ft was #2 " For FCFS update/delete commands, the extension is not= required at all, and therefore the launch:phase is not specified.". &= nbsp;It would be good to hear from others whether the extension should be included for update and delete commands for launch registrations= .  

&n= bsp;

-- 

 

JG

 

 

James Gould

Principal Software Engineer

jgould@verisign.com

 

703-948-3271 (Office)=

12061 Bluemont Way

Reston, VA 20190

VerisignInc.com=

&n= bsp;

From: <Wodjenski>, Sharon <Sharon.Wodjenski@neustar.biz>
Date: Monday, June 3, 2013 2:05 PM
To: EPP Provreg <provreg@ietf= .org>
Subject: [provreg] launch:phase requirement for Sunrise FCFS

&n= bsp;

Hi Everybody,=

 =

We’ve run into a c= ondition during development and are seeking feedback/guidance from the grou= p.

 =

This case is specific to= First Come, First Served Sunrises, and the delete/update commands.

 =

When we read this in the= spec:

 =

2.2.  Launch Phases

 =

   The server MAY support multiple l= aunch phases sequentially or<= /span>

   simultaneously.  The <lau= nch:phase> element MUST be included by the

   client to define the target launc= h phase of the command.

 =

We interpreted that to m= ean that the launch:phase  was mandatory, and would come in with each = command in the extension.

 =

Currently, the XSD for t= he delete/update commands do not support the application id being optional.=   And of course, for a FCFS registration, the application id is not ne= eded/used.

 = 

     <element name=
=3D"update" type=3D"launch:idContainerType"/>
     <element name=
=3D"delete" type=3D"launch:idContainerType"/>
 
     <!--
     Common container =
of id (identifier) element
     -->=

     <complexType n=
ame=3D"idContainerType">
       <s=
equence>
       =
  <element name=3D"phase" type=3D"launch:phaseType&q=
uot;/>
       =
  <element name=3D"applicationID" type=3D"launch:app=
licationIDType"/>
       </=
sequence>
     </complexType&=
gt;

 =

So, the question from a = client perspective is:

 =

1.&nbs= p;       Is the lau= nch:phase, and therefore the extension, mandatory for all commands and the = XSD should be modified so that the application id is optional (as it is in = the Info command)?

Or

2.&nbs= p;      For FCFS update/= delete commands, the extension is not required at all, and therefore the la= unch:phase is not specified.

 =

Thank you for your input= on this topic.

 =

Sharon=

 =

--_000_0607A83C894B824F8778BD69F357FE580AB647DCstntexmb13cisne_-- --_004_0607A83C894B824F8778BD69F357FE580AB647DCstntexmb13cisne_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Tue, 11 Jun 2013 19:39:34 GMT"; modification-date="Tue, 11 Jun 2013 19:39:34 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_0607A83C894B824F8778BD69F357FE580AB647DCstntexmb13cisne_-- From onave@dyn.com Fri Jun 14 09:11:15 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75A721F9B7E for ; Fri, 14 Jun 2013 09:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSGkehhoGjgB for ; Fri, 14 Jun 2013 09:11:15 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6A16C21F9CB2 for ; Fri, 14 Jun 2013 09:11:14 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id ci6so249532qab.18 for ; Fri, 14 Jun 2013 09:11:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=2U7R+EARGAbgj/PUihard445tLsFrDDXrF06Hx2FLSs=; b=SySvOlowypp+knmixE37G7C23ZYU21QXTgAbADjvFmKLB3ANFBTlscwS+dFQor03VL 4Jb7All2Zk49z7ef4WhZ3SI6Da+7IeCG78iXyD0oRPx6YMm64EgDqJwiVPF3/RV98oCK wdgpGoHPOIIehAKxHzYBuibcyRktvlsspI+DZ6ouv6jXHB3d/9VJLzdIJoiB2Yq2phzf Ev9I0BehuU3FxmiSTCnQzeInWGPN8t8c1kecPyIP/LSOkBA7vz9y4Emy/BJh+Gx6jNB7 385fZ/duB+Z0Aa3b6KyBxtwMBPxkcVuyQC6OagrAWx/TNqRXN4nMjP41o9YYCpXjV8IY dKDg== X-Received: by 10.49.107.163 with SMTP id hd3mr3559910qeb.0.1371226260643; Fri, 14 Jun 2013 09:11:00 -0700 (PDT) Received: from ?IPv6:2600:200f:1:30:61a7:d0ed:ebcb:32f5? ([2600:200f:1:30:61a7:d0ed:ebcb:32f5]) by mx.google.com with ESMTPSA id s8sm3711704qat.4.2013.06.14.09.10.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Jun 2013 09:10:59 -0700 (PDT) Message-ID: <51BB4090.6070004@dyn.com> Date: Fri, 14 Jun 2013 12:10:56 -0400 From: Ofer Nave User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: provreg@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQncTPQ9yoKX9EoL7v6OcTOt8UyiQ+GrPsM/Iyab3Rnvox9uEX6XWZvfrPlhq9WgB945/Zaw Subject: [provreg] namestoreExt-1.1 purpose/usage X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 16:12:55 -0000 Hello! I'm new to EPP, and am currently working on an implementation. While implementing the check and info commands against the Verisign OT&E server, I discovered that they require the namestoreExt-1.1 extension to be implemented, which basically means adding something like this to each command frame: dotCOM However, the docs (http://www.verisigninc.com/assets/namestore-extension.pdf) do not mention the purpose of this block, or the valid values. I've guessed from using Verisign's epptool (https://epptool-ctld.verisign-grs.com/epptool/) that the valid values are 'dotCOM', 'dotNET', and 'dotEDU', though I get an authorization error when using 'dotEDU'. However, I'm still confused as to the correct usage. For example, the check command allows you to specify multiple domain names in one frame, which may have multiple TLDs. I tested the submission of a frame checking for 'example.com' and 'example.net' in the same command, once with the subProduct set to 'dotCOM', and once with 'dotNET'. Both times worked fine. So really, what's the point of this extension? And what value am I supposed to provide with it? -ofer From JGould@verisign.com Fri Jun 14 09:55:17 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0B121F99D0 for ; Fri, 14 Jun 2013 09:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gBfDgJntmfv for ; Fri, 14 Jun 2013 09:55:13 -0700 (PDT) Received: from exprod6og109.obsmtp.com (exprod6og109.obsmtp.com [64.18.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id 76DFA21F99A0 for ; Fri, 14 Jun 2013 09:55:11 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKUbtK7wu+S4TpzoXFYIkXtO+jP1Ai6h6+@postini.com; Fri, 14 Jun 2013 09:55:13 PDT Received: from BRN1WNEXCHM01.vcorp.ad.vrsn.com (brn1wnexchm01.vcorp.ad.vrsn.com [10.173.152.255]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r5EGt7Xh003389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Jun 2013 12:55:07 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by BRN1WNEXCHM01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Fri, 14 Jun 2013 12:55:06 -0400 From: "Gould, James" To: Ofer Nave Thread-Topic: [provreg] namestoreExt-1.1 purpose/usage Thread-Index: AQHOaRoJNHJfaBmASUOj9JH9lPSpFpk1rauA Date: Fri, 14 Jun 2013 16:55:06 +0000 Message-ID: References: <51BB4090.6070004@dyn.com> In-Reply-To: <51BB4090.6070004@dyn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <4B3B619BDF18F5448B97AE757767C30D@verisign.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] namestoreExt-1.1 purpose/usage X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 16:55:17 -0000 Ofer, The namestore extension is a routing extension to specify the target regist= ry for the command using a single EPP connection. You must have privileges= to execute a command against a specific target registry (e.g. dotEDU). Th= e check command is currently less strict. The possible values for the exte= nsion currently is the TLD prefixed with "dot" but in the future simply the= TLD will be supported. Please contact Verisign Customer Support if you ha= ve any specific issues or questions. Thanks, JG James F. Gould Principal Engineer Verisign jgould@verisign.com On Jun 14, 2013, at 12:12 PM, "Ofer Nave" wrote: > Hello! >=20 > I'm new to EPP, and am currently working on an implementation. >=20 > While implementing the check and info commands against the Verisign OT&E = server, I discovered that they require the namestoreExt-1.1 extension to be= implemented, which basically means adding something like this to each comm= and frame: >=20 > > > dotCOM > > >=20 > However, the docs (http://www.verisigninc.com/assets/namestore-extension.= pdf) do not mention the purpose of this block, or the valid values. I've g= uessed from using Verisign's epptool (https://epptool-ctld.verisign-grs.com= /epptool/) that the valid values are 'dotCOM', 'dotNET', and 'dotEDU', thou= gh I get an authorization error when using 'dotEDU'. However, I'm still co= nfused as to the correct usage. >=20 > For example, the check command allows you to specify multiple domain name= s in one frame, which may have multiple TLDs. I tested the submission of a= frame checking for 'example.com' and 'example.net' in the same command, on= ce with the subProduct set to 'dotCOM', and once with 'dotNET'. Both times= worked fine. >=20 > So really, what's the point of this extension? And what value am I suppo= sed to provide with it? >=20 > -ofer > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg From keith@blacknight.com Fri Jun 14 10:03:34 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35C621F9CF7 for ; Fri, 14 Jun 2013 10:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXuL+GzgDlj8 for ; Fri, 14 Jun 2013 10:03:30 -0700 (PDT) Received: from nineve.blacknight.ie (nineve.blacknight.ie [81.17.243.129]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF2421F9CF6 for ; Fri, 14 Jun 2013 10:03:30 -0700 (PDT) Received: by nineve.blacknight.ie (Postfix, from userid 1010) id ADB795808C; Fri, 14 Jun 2013 18:03:28 +0100 (IST) Date: Fri, 14 Jun 2013 18:03:28 +0100 From: Keith Gaughan To: Ofer Nave Message-ID: <20130614170328.GT31423@nineve.blacknight.ie> References: <20130614161125.CC0B75B4016@merlin.blacknight.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130614161125.CC0B75B4016@merlin.blacknight.ie> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: provreg@ietf.org Subject: Re: [provreg] namestoreExt-1.1 purpose/usage X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 17:03:34 -0000 On Fri, Jun 14, 2013 at 12:10:56PM -0400, Ofer Nave wrote: > I'm new to EPP, and am currently working on an implementation. > > While implementing the check and info commands against the Verisign > OT&E server, I discovered that they require the namestoreExt-1.1 > extension to be implemented, which basically means adding something > like this to each command frame: This isn't really the best list to be contacting on this subject. That's a VeriSign specific extension. You really ought to be contacting VeriSign's own support desk. However... > > > dotCOM > > The namestore extension is used by Verisign's EPP infrastructure to enable proxying of requests. You see, the EPP server you connect to is simply a proxy in front of other zone-specific EPP serves, so there's one for .com, one for .net, &c. To determine which of these backend EPP servers the request is to be directed to, you include the namestore extension. Thus, the subproduct 'dotCOM' indicates that the request should be forwarded to the .com backend EPP server, and so on. I agree that it's not particularly clear. In my head, this kind of proxying ought to be done at a transport level rather than at an application level, but that's the way it's implemented in VeriSign's case. K. -- Keith Gaughan, Development Lead PGP/GPG key ID: 82AC3634 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From sethamin@google.com Mon Jun 17 12:02:01 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800D321F9A6D for ; Mon, 17 Jun 2013 12:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Rvi25QHCdfg for ; Mon, 17 Jun 2013 12:01:51 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C47121F8EDF for ; Mon, 17 Jun 2013 12:01:28 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id z10so3085215pdj.17 for ; Mon, 17 Jun 2013 12:01:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NbNDraozl581394PSJjywoCzJiwTos6x1fMAZqKjj80=; b=FnQz+K39gg9NqY76/CA1fdxPMnOTjn00KD4fLPcKQP08vpzt8Mcsz2y65twbNfh5B8 cHKeYM7M5vOwFBEEbKMG8C9CCMiqr2DZcskNc1d6qbivphy3vrMqPKqbUpa0wgNR7LF1 lm87SgXvWVSk//cS8VKuP/29bL3dHVOaDfLkBoOVpkAb2gnXJXqYayxu1Wxek23s0bcz /2TVCATtlAlRTTXGVVJF1h8i3marDJTuyYGOJhENoGubf88VEGZGSrPbW10Sp5ZNk23w Pj5HQJWOzHAoJqbDXvtq+Y00tTXKZ1uk4yMfYVSFQG6oG9lfUNVZmLN1aG0hCHkg2hMv T23Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=NbNDraozl581394PSJjywoCzJiwTos6x1fMAZqKjj80=; b=YXyXfdyYQ1iYx/u5VKtY8AvoTB0Md5R4GvxwmG76+5DAuwrG1eKF26rRsXa4GecFc7 iAETNgaPHBSNI3CjDYibN3UQlqToKSqzR5z0rXp0DRWWu7h4K23cPgQCF/eAjaabi0yG cAbw6+8kH1GDVyv42z/KOyjVSIRjIPzuC24S1gBJFrQ1kizpfrR6mkQV+bWdPha+Tyq8 S2zP9dlYJpy5R9m6iD8dJ8kybWqNpr18V7P4cojMeGWReBMhSnSEF0u4uFkGPNpZO+X8 yEvYonmHODppoxRrdHd0ejEPF9uxpzT8X4CR6XPqEyAoa14fFxLMJ/6bSAH1mRJ4FRVz eplA== MIME-Version: 1.0 X-Received: by 10.66.158.36 with SMTP id wr4mr13966463pab.28.1371495687773; Mon, 17 Jun 2013 12:01:27 -0700 (PDT) Received: by 10.70.39.5 with HTTP; Mon, 17 Jun 2013 12:01:27 -0700 (PDT) In-Reply-To: <0607A83C894B824F8778BD69F357FE580AB647DC@stntexmb13.cis.neustar.com> References: <0607A83C894B824F8778BD69F357FE580AB5A946@stntexmb13.cis.neustar.com> <0607A83C894B824F8778BD69F357FE580AB647DC@stntexmb13.cis.neustar.com> Date: Mon, 17 Jun 2013 15:01:27 -0400 Message-ID: From: Seth Goldman To: "Wodjenski, Sharon" Content-Type: multipart/related; boundary=047d7b86f45e4804c404df5e3950 X-Gm-Message-State: ALoCoQlhbp7r/F4p+lmSiEwiVc7/sIgQ5B+8ho8fz26h34927wsaheuURwAqg6TaBsTqOJI4Em1G+aozAcqeJmO2aGecnquHKGyrZVjERQRX6YsbdS/YTHbP/k8IPOPcorQ1DkShqt4Jcm0wgapW6P/kbM9naOo/G9CIqVqwDyPhO0xYbtPjtTEC+oC/MT0VxJWbqwpAn21I Cc: "provreg@ietf.org" Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 19:02:01 -0000 --047d7b86f45e4804c404df5e3950 Content-Type: multipart/alternative; boundary=047d7b86f45e4804c104df5e394f --047d7b86f45e4804c104df5e394f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think the idea of the launch update/delete commands is to support operations on applications. If you've already provisioned the domain (presumably you have since it's FCFS), then the standard version of update and delete should be sufficient, in which case you don't need to specify either a phase or an application id. On Tue, Jun 11, 2013 at 3:39 PM, Wodjenski, Sharon < Sharon.Wodjenski@neustar.biz> wrote: > As we have not received any feedback, we will take Jim=92s suggestion an= d > not require the launch extension and launch:phase for update/delete > commands in FCFS Sunrise.**** > > ** ** > > Jim =96 could you please update the text in the next revision to clarify > this point?**** > > ** ** > > Thanks,**** > > ** ** > > Sharon**** > > ** ** > > *From:* Gould, James [mailto:JGould@verisign.com] > *Sent:* Monday, June 03, 2013 6:26 PM > *To:* Wodjenski, Sharon; 'provreg@ietf.org' > *Subject:* Re: [provreg] launch:phase requirement for Sunrise FCFS**** > > ** ** > > Sharon,**** > > ** ** > > The intention in the draft was #2 " For FCFS update/delete commands, the > extension is not required at all, and therefore the launch:phase is not > specified.". It would be good to hear from others whether the extension > should be included for update and delete commands for launch registration= s. > **** > > ** ** > > -- **** > > **** > > JG**** > > **** > > **** > > **** > > James Gould**** > > Principal Software Engineer**** > > jgould@verisign.com**** > > **** > > 703-948-3271 (Office)**** > > 12061 Bluemont Way**** > > Reston, VA 20190**** > > VerisignInc.com**** > > ** ** > > *From: *, Sharon > *Date: *Monday, June 3, 2013 2:05 PM > *To: *EPP Provreg > *Subject: *[provreg] launch:phase requirement for Sunrise FCFS**** > > ** ** > > Hi Everybody,**** > > **** > > We=92ve run into a condition during development and are seeking > feedback/guidance from the group.**** > > **** > > This case is specific to First Come, First Served Sunrises, and the > delete/update commands.**** > > **** > > When we read this in the spec:**** > > **** > > 2.2. Launch Phases**** > > **** > > The server MAY support multiple launch phases sequentially or**** > > simultaneously. The element MUST be included by the***= * > > client to define the target launch phase of the command. **** > > **** > > We interpreted that to mean that the launch:phase was mandatory, and > would come in with each command in the extension.**** > > **** > > Currently, the XSD for the delete/update commands do not support the > application id being optional. And of course, for a FCFS registration, t= he > application id is not needed/used.**** > > **** > > **** > > **** > > **** > > **** > > **** > > **** > > **** > > **** > > **** > > **** > > **** > > So, the question from a client perspective is:**** > > **** > > **1. ** Is the launch:phase, and therefore the extension, mandatory > for all commands and the XSD should be modified so that the application i= d > is optional (as it is in the Info command)? **** > > Or**** > > **2. **For FCFS update/delete commands, the extension is not > required at all, and therefore the launch:phase is not specified.**** > > **** > > Thank you for your input on this topic.**** > > **** > > Sharon**** > > **** > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > > --047d7b86f45e4804c104df5e394f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I think the idea of the launch update/delete commands is t= o support operations on applications. If you've already provisioned the= domain (presumably you have since it's FCFS), then the standard versio= n of update and delete should be sufficient, in which case you don't ne= ed to specify either a phase or an application id.


On Tue, Jun 1= 1, 2013 at 3:39 PM, Wodjenski, Sharon <Sharon.Wodjenski@neustar= .biz> wrote:

As we have not receive= d any feedback, we will take Jim=92s suggestion and not require the launch = extension and launch:phase for update/delete commands in FCFS Sunrise.

=A0

Jim =96 could you plea= se update the text in the next revision to clarify this point?

=A0

Thanks,<= /span>

=A0

Sharon

=A0

From: Gould, J= ames [mailto:JGoul= d@verisign.com]
Sent: Monday, June 03, 2013 6:26 PM
To: Wodjenski, Sharon; 'provreg@ietf.org'
Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS<= /u>

=A0

Sharon,

=A0

The intention in the draft was #2 "= =A0For FCFS update/delete commands, the extension is not required at all, a= nd therefore the launch:phase is not specified.". =A0It would be good = to hear from others whether the extension should be included for update and delete commands for launch registrations= . =A0

=A0

--=A0

=A0

JG

=A0

=A0

James Gould

Principal Software Eng= ineer

jgould@verisign.com

=A0

703-948-3271 (Office)<= /span>=

12061 Bluemont Way

Reston, VA 20190<= u>

VerisignInc.com=

=A0

From: <Wodj= enski>, Sharon <Sharon.Wodjenski@neustar.biz>
Date: Monday, June 3, 2013 2:05 PM
To: EPP Provreg <provreg@ietf.org>
Subject: [provreg] launch:phase requirement for Sunrise FCFS<= u>

=A0

Hi Everybody,

=A0

We=92ve run into a condition during deve= lopment and are seeking feedback/guidance from the group.

=A0

This case is specific to First Come, Fir= st Served Sunrises, and the delete/update commands.

=A0

When we read this in the spec:=

=A0

2.2.=A0 Launch Phases

=A0

=A0=A0 The server MAY support multiple launch phases seque= ntially or

=A0=A0 simultaneously.=A0 The <launch:phase> element= MUST be included by the

=A0=A0 client to define the target launch phase of the com= mand.

=A0

We interpreted that to mean that the lau= nch:phase=A0 was mandatory, and would come in with each command in the exte= nsion.

=A0

Currently, the XSD for the delete/update= commands do not support the application id being optional.=A0 And of cours= e, for a FCFS registration, the application id is not needed/used.

=A0

=A0=A0=A0=A0 <element name=3D"update" type=3D=
"launch:idContainerType"/>
=A0=A0=A0=A0 <element name=3D"delete" type=3D=
"launch:idContainerType"/>
=A0
=A0=A0=A0=A0 <!--
=A0=A0=A0=A0 Common container of id (identifier) element
=A0=A0=A0=A0 -->
=A0=A0=A0=A0 <complexType name=3D"idContainerType&=
quot;>
=A0=A0=A0=A0=A0=A0 <sequence>

=A0=A0=A0=A0=A0=A0=A0=A0 <element name=3D"phase&qu=
ot; type=3D"launch:phaseType"/>


=A0=A0=A0=A0=A0=A0=A0=A0 <element name=3D"applicat=
ionID" type=3D"launch:applicationIDType"/><=
/span>


=A0=A0=A0=A0=A0=A0 </sequence><=
/pre>

=A0=A0=A0=A0 </complexType>

=A0


So, the question from a client perspecti=
ve is:


=A0


1.=A0=A0=A0=A0=A0=A0
=A0Is the launch:phase, and therefo=
re the extension, mandatory for all commands and the XSD should be modified=
 so that the application id is optional (as it is in the Info command)?



Or


2.=A0=A0=A0=A0=A0=A0
For FCFS update/delete commands, th=
e extension is not required at all, and therefore the launch:phase is not s=
pecified.


=A0


Thank you for your input on this topic.<=
u>


=A0


Sharon


=A0

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


--047d7b86f45e4804c104df5e394f-- --047d7b86f45e4804c404df5e3950 Content-Type: image/png; name="image001.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: fcc99677b3449201_0.0.1 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --047d7b86f45e4804c404df5e3950-- From sharon.wodjenski@neustar.biz Mon Jun 17 12:35:15 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7FE021E8053 for ; Mon, 17 Jun 2013 12:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.722 X-Spam-Level: X-Spam-Status: No, score=-4.722 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rvCbbsg2zDB for ; Mon, 17 Jun 2013 12:35:12 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 8D24521F9DF2 for ; Mon, 17 Jun 2013 12:35:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1371497891; x=1686857834; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=a16brd2kSD/xW9rHjFAleT7CPR0d576PecTOb6en9fQ=; b=cBXt++D1uir9DgPDMmrDM1DZ05p1Uvf6tZjrwSY7fOGZnmbu97xqy2s3RIBKsf 5O/wurt3WjZTN0Jpy+7D8ITw== Received: from ([10.31.58.70]) by stihiron2.va.neustar.com with ESMTP with TLS id J041124103.25243429; Mon, 17 Jun 2013 15:36:56 -0400 Received: from STNTEXMB13.cis.neustar.com ([169.254.3.23]) by stntexhc11.cis.neustar.com ([::1]) with mapi id 14.02.0342.003; Mon, 17 Jun 2013 15:33:53 -0400 From: "Wodjenski, Sharon" To: 'Seth Goldman' Thread-Topic: [provreg] launch:phase requirement for Sunrise FCFS Thread-Index: Ac5ghOmgGmHsL01wQnGL+KYsyzPB/AAJGSwAAYxz2rABNN68gAAHRaFA Date: Mon, 17 Jun 2013 19:33:52 +0000 Message-ID: <0607A83C894B824F8778BD69F357FE580AB6BE5F@stntexmb13.cis.neustar.com> References: <0607A83C894B824F8778BD69F357FE580AB5A946@stntexmb13.cis.neustar.com> <0607A83C894B824F8778BD69F357FE580AB647DC@stntexmb13.cis.neustar.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.33.200.57] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: zIdutqkHWJyHwh9lAhSbvg== Content-Type: multipart/related; boundary="_004_0607A83C894B824F8778BD69F357FE580AB6BE5Fstntexmb13cisne_"; type="multipart/alternative" MIME-Version: 1.0 Cc: "provreg@ietf.org" Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 19:35:16 -0000 --_004_0607A83C894B824F8778BD69F357FE580AB6BE5Fstntexmb13cisne_ Content-Type: multipart/alternative; boundary="_000_0607A83C894B824F8778BD69F357FE580AB6BE5Fstntexmb13cisne_" --_000_0607A83C894B824F8778BD69F357FE580AB6BE5Fstntexmb13cisne_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thank you for the confirmation Seth. Sharon From: Seth Goldman [mailto:sethamin@google.com] Sent: Monday, June 17, 2013 3:01 PM To: Wodjenski, Sharon Cc: Gould, James; provreg@ietf.org Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS I think the idea of the launch update/delete commands is to support operati= ons on applications. If you've already provisioned the domain (presumably y= ou have since it's FCFS), then the standard version of update and delete sh= ould be sufficient, in which case you don't need to specify either a phase = or an application id. On Tue, Jun 11, 2013 at 3:39 PM, Wodjenski, Sharon > wrote: As we have not received any feedback, we will take Jim's suggestion and not= require the launch extension and launch:phase for update/delete commands i= n FCFS Sunrise. Jim - could you please update the text in the next revision to clarify this= point? Thanks, Sharon From: Gould, James [mailto:JGould@verisign.com] Sent: Monday, June 03, 2013 6:26 PM To: Wodjenski, Sharon; 'provreg@ietf.org' Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS Sharon, The intention in the draft was #2 " For FCFS update/delete commands, the ex= tension is not required at all, and therefore the launch:phase is not speci= fied.". It would be good to hear from others whether the extension should = be included for update and delete commands for launch registrations. -- JG [cid:image001.png@01CE6B70.11C586B0] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: , Sharon > Date: Monday, June 3, 2013 2:05 PM To: EPP Provreg > Subject: [provreg] launch:phase requirement for Sunrise FCFS Hi Everybody, We've run into a condition during development and are seeking feedback/guid= ance from the group. This case is specific to First Come, First Served Sunrises, and the delete/= update commands. When we read this in the spec: 2.2. Launch Phases The server MAY support multiple launch phases sequentially or simultaneously. The element MUST be included by the client to define the target launch phase of the command. We interpreted that to mean that the launch:phase was mandatory, and would= come in with each command in the extension. Currently, the XSD for the delete/update commands do not support the applic= ation id being optional. And of course, for a FCFS registration, the appli= cation id is not needed/used. So, the question from a client perspective is: 1. Is the launch:phase, and therefore the extension, mandatory for a= ll commands and the XSD should be modified so that the application id is op= tional (as it is in the Info command)? Or 2. For FCFS update/delete commands, the extension is not required at = all, and therefore the launch:phase is not specified. Thank you for your input on this topic. Sharon _______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg --_000_0607A83C894B824F8778BD69F357FE580AB6BE5Fstntexmb13cisne_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thank you for the confirm= ation Seth.

 <= /p>

Sharon<= /p>

 <= /p>

From: Seth Gol= dman [mailto:sethamin@google.com]
Sent: Monday, June 17, 2013 3:01 PM
To: Wodjenski, Sharon
Cc: Gould, James; provreg@ietf.org
Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS

 

I think the idea of the launch update/delete command= s is to support operations on applications. If you've already provisioned t= he domain (presumably you have since it's FCFS), then the standard version = of update and delete should be sufficient, in which case you don't need to specify either a phase or an application i= d.

 

On Tue, Jun 11, 2013 at 3:39 PM, Wodjenski, Sharon &= lt;Sharon= .Wodjenski@neustar.biz> wrote:

As we have not received any feedback= , we will take Jim’s suggestion and not require the launch extension = and launch:phase for update/delete commands in FCFS Sunrise.

 

Jim – could you please update = the text in the next revision to clarify this point?

 

Thanks,

 

Sharon

 

From: Gould, James [mailto:<= a href=3D"mailto:JGould@verisign.com" target=3D"_blank">JGould@verisign.com= ]
Sent: Monday, June 03, 2013 6:26 PM
To: Wodjenski, Sharon; 'provreg@ietf.org'
Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS

 

Sharon,

 

The intention in the draft was #2 " For FCFS update/dele= te commands, the extension is not required at all, and therefore the launch= :phase is not specified.".  It would be good to hear from others whether the extension should be included for update and d= elete commands for launch registrations.  

 

-- 

 

JG

 

 

James Gould

Principal Software Engineer

jgould@verisign.com

 

703-948-3271 (Office)

12061 Bluemont Way=

Reston, VA 20190

VerisignInc.com

 

From: <Wodjenski>, Sharon <Sharon.Wodjenski@neustar.biz>
Date: Monday, June 3, 2013 2:05 PM
To: EPP Provreg <provreg@ietf.org>
Subject: [provreg] launch:phase requirement for Sunrise FCFS

 

Hi Everybody,

 

We’ve run into a condition during development and are seekin= g feedback/guidance from the group.

 

This case is specific to First Come, First Served Sunrises, and th= e delete/update commands.

 

When we read this in the spec:

 

2.2.  Launch Phases

 

   The server MAY support multiple launch phases sequentially = or

   simultaneously.  The <launch:phase> element MUST= be included by the

   client to define the target launch phase of the command.

 

We interpreted that to mean that the launch:phase  was mandat= ory, and would come in with each command in the extension.

 

Currently, the XSD for the delete/update commands do not support t= he application id being optional.  And of course, for a FCFS registrat= ion, the application id is not needed/used.

 

     <element name=3D"update" type=3D=
"launch:idContainerType"/>
     <element name=3D"delete" type=3D=
"launch:idContainerType"/>
 
     <!--
     Common container of id (identifier) element
     -->
     <complexType name=3D"idContainerType&=
quot;>
       <sequence>
         <element name=3D&q=
uot;phase" type=3D"launch:phaseType"/>
         <element name=3D&q=
uot;applicationID" type=3D"launch:applicationIDType"/>
       </sequence>

     </complexType>


 


So, the question from a client perspective is:


 


1.       <=
/span> Is the launch:phase, and therefore the extension, mandatory for=
 all commands and the XSD should be modified so that the application id is =
optional (as it is in the Info command)?



Or


2.       <=
/span>For FCFS update/delete commands, the extension is not required at all=
, and therefore the launch:phase is not specified.


 


Thank you for your input on this topic.


 


Sharon


 


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

 

--_000_0607A83C894B824F8778BD69F357FE580AB6BE5Fstntexmb13cisne_-- --_004_0607A83C894B824F8778BD69F357FE580AB6BE5Fstntexmb13cisne_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=4109; creation-date="Mon, 17 Jun 2013 19:33:51 GMT"; modification-date="Mon, 17 Jun 2013 19:33:51 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_0607A83C894B824F8778BD69F357FE580AB6BE5Fstntexmb13cisne_-- From JGould@verisign.com Mon Jun 17 12:45:30 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2140121F9970 for ; Mon, 17 Jun 2013 12:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.998 X-Spam-Level: X-Spam-Status: No, score=-5.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_65=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GsratKKcer1d for ; Mon, 17 Jun 2013 12:45:25 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id B4F5821F9DE5 for ; Mon, 17 Jun 2013 12:45:23 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKUb9nUwsZcIxXLWWcxoqFR+unzYEOx4Vt@postini.com; Mon, 17 Jun 2013 12:45:24 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id r5HJjMuN026260 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Jun 2013 15:45:22 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Mon, 17 Jun 2013 15:45:22 -0400 From: "Gould, James" To: "Wodjenski, Sharon" , "'provreg@ietf.org'" Thread-Topic: [provreg] launch:phase requirement for Sunrise FCFS Thread-Index: Ac5ghOmgGmHsL01wQnGL+KYsyzPB/AAJGSwAAYxz2rABLgQfAA== Date: Mon, 17 Jun 2013 19:45:21 +0000 Message-ID: In-Reply-To: <0607A83C894B824F8778BD69F357FE580AB647DC@stntexmb13.cis.neustar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: multipart/mixed; boundary="_006_CDE4DEA75130Fjgouldverisigncom_" MIME-Version: 1.0 Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 19:45:30 -0000 --_006_CDE4DEA75130Fjgouldverisigncom_ Content-Type: multipart/related; boundary="_005_CDE4DEA75130Fjgouldverisigncom_"; type="multipart/alternative" --_005_CDE4DEA75130Fjgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CDE4DEA75130Fjgouldverisigncom_" --_000_CDE4DEA75130Fjgouldverisigncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sharon, We can add some clarifying text to the next version of the draft. I don't = believe that this change alone warrants a new draft version, so we can wait= to include it with other updates. Thanks, -- JG [cid:6C2EF356-04B3-47CE-BA8E-B8D03B93BB08] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: , Sharon > Date: Tuesday, June 11, 2013 3:39 PM To: James Gould >, EPP Prov= reg > Subject: RE: [provreg] launch:phase requirement for Sunrise FCFS As we have not received any feedback, we will take Jim=92s suggestion and n= ot require the launch extension and launch:phase for update/delete commands= in FCFS Sunrise. Jim =96 could you please update the text in the next revision to clarify th= is point? Thanks, Sharon From: Gould, James [mailto:JGould@verisign.com] Sent: Monday, June 03, 2013 6:26 PM To: Wodjenski, Sharon; 'provreg@ietf.org' Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS Sharon, The intention in the draft was #2 " For FCFS update/delete commands, the ex= tension is not required at all, and therefore the launch:phase is not speci= fied.". It would be good to hear from others whether the extension should = be included for update and delete commands for launch registrations. -- JG [cid:image001.png@01CE66B9.DF555EE0] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: , Sharon > Date: Monday, June 3, 2013 2:05 PM To: EPP Provreg > Subject: [provreg] launch:phase requirement for Sunrise FCFS Hi Everybody, We=92ve run into a condition during development and are seeking feedback/gu= idance from the group. This case is specific to First Come, First Served Sunrises, and the delete/= update commands. When we read this in the spec: 2.2. Launch Phases The server MAY support multiple launch phases sequentially or simultaneously. The element MUST be included by the client to define the target launch phase of the command. We interpreted that to mean that the launch:phase was mandatory, and would= come in with each command in the extension. Currently, the XSD for the delete/update commands do not support the applic= ation id being optional. And of course, for a FCFS registration, the appli= cation id is not needed/used. So, the question from a client perspective is: 1. Is the launch:phase, and therefore the extension, mandatory for a= ll commands and the XSD should be modified so that the application id is op= tional (as it is in the Info command)? Or 2. For FCFS update/delete commands, the extension is not required at = all, and therefore the launch:phase is not specified. Thank you for your input on this topic. Sharon --_000_CDE4DEA75130Fjgouldverisigncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6636DEB478F0C142A2FBA18B6B5714E5@verisign.com> Content-Transfer-Encoding: quoted-printable
Sharon,

We can add some clarifying text to the next version of the draft. &nbs= p;I don't believe that this change alone warrants a new draft version, so w= e can wait to include it with other updates.  

Thanks,

-- 

 

JG

 

 

James Gould

= Principal Software Engineer

j= gould@verisign.com

=  

= 703-948-3271 (Office)

= 12061 Bluemont Way

= Reston, VA 20190

VerisignInc.com


From: <Wodjenski>, Sharon <= ;Sharon.Wodjenski@neustar.b= iz>
Date: Tuesday, June 11, 2013 3:39 P= M
To: James Gould <jgould@verisign.com>, EPP Provreg <provreg@ietf.org>
Subject: RE: [provreg] launch:phase= requirement for Sunrise FCFS

As we have not receive= d any feedback, we will take Jim=92s suggestion and not require the launch = extension and launch:phase for update/delete commands in FCFS Sunrise.=

 

Jim =96 could you plea= se update the text in the next revision to clarify this point?

 

Thanks,

 

Sharon

 

From: Gould, James [mailto:JGould@verisign.com]
Sent: Monday, June 03, 2013 6:26 PM
To: Wodjenski, Sharon; 'provreg= @ietf.org'
Subject: Re: [provreg] launch:phase requirement for Sunrise FCFS

 

Sharon,=

&n= bsp;

The intention in the dra= ft was #2 " For FCFS update/delete commands, the extension is not= required at all, and therefore the launch:phase is not specified.". &= nbsp;It would be good to hear from others whether the extension should be included for update and delete commands for launch registrations= .  

&n= bsp;

-- 

 

JG

 

 

James Gould

Principal Software Engineer

jgould@verisign.com

 

703-948-3271 (Office)

12061 Bluemont Way

Reston, VA 20190

VerisignInc.com

&n= bsp;

From: <Wodjenski>, Sharon <Sharon.Wodjenski@neustar.biz>
Date: Monday, June 3, 2013 2:05 PM
To: EPP Provreg <provreg@ietf= .org>
Subject: [provreg] launch:phase requirement for Sunrise FCFS

&n= bsp;

Hi Everybody,=

 =

We=92ve run into a condi= tion during development and are seeking feedback/guidance from the group.

 =

This case is specific to= First Come, First Served Sunrises, and the delete/update commands.

 =

When we read this in the= spec:

 =

2.2.  Launch Phases

 

   The server MAY support multiple launch= phases sequentially or

   simultaneously.  The <launch:p= hase> element MUST be included by the=

   client to define the target launch pha= se of the command.

 

We interpreted that to m= ean that the launch:phase  was mandatory, and would come in with each = command in the extension.

 =

Currently, the XSD for t= he delete/update commands do not support the application id being optional.=   And of course, for a FCFS registration, the application id is not ne= eded/used.

 = 

     <element name=
=3D"update" type=3D"launch:idContainerType"/>
     <element name=
=3D"delete" type=3D"launch:idContainerType"/>
 
     <!--
     Common container =
of id (identifier) element
     -->=

     <complexType n=
ame=3D"idContainerType">
       <s=
equence>
       =
  <element name=3D"phase" type=3D"launch:phaseType&q=
uot;/>
       =
  <element name=3D"applicationID" type=3D"launch:app=
licationIDType"/>
       </=
sequence>
     </complexType&=
gt;

 

So, the question from a = client perspective is:

 =

1.        Is the= launch:phase, and therefore the extension, mandatory for all commands and = the XSD should be modified so that the application id is optional (as it is= in the Info command)?

Or

2.       For FCFS upd= ate/delete commands, the extension is not required at all, and therefore th= e launch:phase is not specified.

 =

Thank you for your input= on this topic.

 =

Sharon=

 =

--_000_CDE4DEA75130Fjgouldverisigncom_-- --_005_CDE4DEA75130Fjgouldverisigncom_ Content-Type: image/png; name="8A7A655D-9ED0-4D38-898D-E9E8B754666E[8].png" Content-Description: 8A7A655D-9ED0-4D38-898D-E9E8B754666E[8].png Content-Disposition: inline; filename="8A7A655D-9ED0-4D38-898D-E9E8B754666E[8].png"; size=4109; creation-date="Mon, 17 Jun 2013 19:45:21 GMT"; modification-date="Mon, 17 Jun 2013 19:45:21 GMT" Content-ID: <6C2EF356-04B3-47CE-BA8E-B8D03B93BB08> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_005_CDE4DEA75130Fjgouldverisigncom_-- --_006_CDE4DEA75130Fjgouldverisigncom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: attachment; filename="image001.png"; size=4109; creation-date="Mon, 17 Jun 2013 19:45:21 GMT"; modification-date="Mon, 17 Jun 2013 19:45:21 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_006_CDE4DEA75130Fjgouldverisigncom_-- From sethamin@google.com Tue Jun 18 13:42:18 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD93111E8100 for ; Tue, 18 Jun 2013 13:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWQOTkOhvgs0 for ; Tue, 18 Jun 2013 13:42:18 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5288011E80F1 for ; Tue, 18 Jun 2013 13:42:13 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b12so3878355wgh.19 for ; Tue, 18 Jun 2013 13:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=KGmxGp+554UaF2z+oY9RYUyz0t90hWcFCyzph3yHfyg=; b=VlxhxMEPNKgBuLwJRSriS7qSrt3kDWHMcZiXFnc55l+yaVkwgfI6MQcHrzpL/0h5FY Xa0TwkaKm/nUsFxElPuSUv5QE95iqJnebSbf9fdoTz801c17xVc+vEK0H7WwMWVnJIkJ MohEhuGSbHNNcQHKY1RzZycQPYQ1U0373tmkSMoEm0OfUYCZGf0W2qU/40XsKycTOBkH +A+xjBSPjKNvI8sEFfBZp5RYSluECC/BrcvEYzu4i0mLtIBmYqePd4SdsFdckeVzqKVn hcXsvfn2A7IQCWWvEY7vENf0gfNGrT1debERiuEIaUuKCKPHrsOWDDp2O+fhlPXajlbA GFug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=KGmxGp+554UaF2z+oY9RYUyz0t90hWcFCyzph3yHfyg=; b=QnTWre9TSwLLlLLmW/z5Su1IzWOlCxw1FrTqbyTnFqHbn4COKmGof7Vpng321+5R+p AasBh/v7Fb3BtKK6mtn8h2z0XsCHIDdEH8LGM8x0R/WVR1uw91LPlcMOaC+IVV3BHI0k IxQtV7Gwq6VcGr7YLhKhhEBdnPtu9v8K5ltY5CHXDfgmoorJNE0cnVViOJzywcD65IHR 5LYnn5ePxM21vMrGrQNMsnKTeELZ2tIh/s/G7w2/6sHBciwSi4sAelwKXPhaRvoI6nAk OPOqf8rqTf2Xuk7l1GNaMuRldtw6v3FfdzYMVIxmv4sNfrh4KATUstXYNwwrB3BIPaPG Z/4Q== MIME-Version: 1.0 X-Received: by 10.180.85.6 with SMTP id d6mr8614602wiz.47.1371588133273; Tue, 18 Jun 2013 13:42:13 -0700 (PDT) Received: by 10.194.239.162 with HTTP; Tue, 18 Jun 2013 13:42:13 -0700 (PDT) Date: Tue, 18 Jun 2013 16:42:13 -0400 Message-ID: From: Seth Goldman To: EPP Provreg Content-Type: multipart/alternative; boundary=f46d0442808e7656a704df73bfd8 X-Gm-Message-State: ALoCoQmzFYrdcv3YuVl1igBfTNiKsHEVBzC3xh+I8uNYeoWZCuBdSLeoNdwBMKzB/CurlO8id+Pkk7Zlx+/yigZtxwN7hGge2MlALaP6ocnto3htUAe32w8HKLFNDxn2wuCaxlN95+PG56AQ0dP+y2nbeaZFhUPmdEYJxrj6FSw8yv1tBGTPdSYXUs+2UiS+j9F4hj5FqSTB Subject: [provreg] Are escrow deposit files per-TLD, or per-registry operator? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:42:18 -0000 --f46d0442808e7656a704df73bfd8 Content-Type: text/plain; charset=ISO-8859-1 In the case of a registry operator who operates multiple TLDs in a single database, are the escrow deposit files intended to be per-TLD? Or per-registry operator? My suspicion is that it should be the latter. The entire reason for the escrow deposit to exist is to transition to an EBERO in the event that a registry operator is unable to perform its duties. That could happen on a per-TLD basis, but it would be a lot more efficient to do it for *all* TLDs that are managed by that registry operator. So if that is the case, what are we to make of the escrow deposit file naming convention? Files will be named according to the following convention: > > {gTLD}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext} where: > 5.1 {gTLD} is replaced with the gTLD name; in case of an IDN-TLD, the > ASCII-compatible form > (A-Label) must be used; If there is a single escrow file with multiple TLDs embedded in it, what would you use for "{gTLD}"? Is the assumption that all TLDs will be stored in totally separate databases? Or that they should be written to separate files, even if stored in the same database? That would mean that shared objects (e.g. contacts, hosts, etc.) would have to be written multiple times. That seems less than ideal. --f46d0442808e7656a704df73bfd8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In the case of a registry operator who operates multiple T= LDs in a single database, are the escrow deposit files intended to be per-T= LD? Or per-registry operator?

My suspicion is that= it should be the latter. The entire reason for the escrow deposit to exist= is to transition to an EBERO in the event that a registry operator is unab= le to perform its duties. That could happen on a per-TLD basis, but it woul= d be a lot more efficient to do it for *all* TLDs that are managed by that = registry operator.

So if that is the case, what are we to make= of the escrow deposit file naming convention?

Files will be named according to the following convention:
=
=A0
{gTLD}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext} where:
5.1 {gTLD} is replac= ed with the gTLD name; in case of an IDN-TLD, the ASCII-compatible form
= (A-Label) must be used;

If ther= e is a single escrow file with multiple TLDs embedded in it, what would you= use for "{gTLD}"? Is the assumption that all TLDs will be stored= in totally separate databases? Or that they should be written to separate = files, even if stored in the same database? That would mean that shared obj= ects (e.g. contacts, hosts, etc.) would have to be written multiple times. = That seems less than ideal.
--f46d0442808e7656a704df73bfd8-- From JGould@verisign.com Tue Jun 18 13:47:37 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432D521E8097 for ; Tue, 18 Jun 2013 13:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXZ7TnZoWwFw for ; Tue, 18 Jun 2013 13:47:32 -0700 (PDT) Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5D90A21E8096 for ; Tue, 18 Jun 2013 13:47:31 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKUcDHYgGaZWdIo0omeCh4RT32+Erg/ngw@postini.com; Tue, 18 Jun 2013 13:47:32 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r5IKlQ1q020227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 16:47:26 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Tue, 18 Jun 2013 16:47:25 -0400 From: "Gould, James" To: Seth Goldman , EPP Provreg Thread-Topic: [provreg] Are escrow deposit files per-TLD, or per-registry operator? Thread-Index: AQHObGUJIO4A235sS0CgGbd4gZsoQw== Date: Tue, 18 Jun 2013 20:47:25 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_CDE63F2151447jgouldverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [provreg] Are escrow deposit files per-TLD, or per-registry operator? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:47:37 -0000 --_004_CDE63F2151447jgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CDE63F2151447jgouldverisigncom_" --_000_CDE63F2151447jgouldverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Seth, You might want to post this to the Internet Registration Escrow (IRE) list = ( https://www.ietf.org/mailman/listinfo/ire ). My understanding is that th= e deposits are per-TLD and not per registry operator. -- JG [cid:330C1C8F-95EE-4160-BE78-8271CD0967B2] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Seth Goldman > Date: Tuesday, June 18, 2013 4:42 PM To: EPP Provreg > Subject: [provreg] Are escrow deposit files per-TLD, or per-registry operat= or? In the case of a registry operator who operates multiple TLDs in a single d= atabase, are the escrow deposit files intended to be per-TLD? Or per-regist= ry operator? My suspicion is that it should be the latter. The entire reason for the esc= row deposit to exist is to transition to an EBERO in the event that a regis= try operator is unable to perform its duties. That could happen on a per-TL= D basis, but it would be a lot more efficient to do it for *all* TLDs that = are managed by that registry operator. So if that is the case, what are we to make of the escrow deposit file nami= ng convention? Files will be named according to the following convention: {gTLD}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext} where: 5.1 {gTLD} is replaced with the gTLD name; in case of an IDN-TLD, the ASCII= -compatible form (A-Label) must be used; If there is a single escrow file with multiple TLDs embedded in it, what wo= uld you use for "{gTLD}"? Is the assumption that all TLDs will be stored in= totally separate databases? Or that they should be written to separate fil= es, even if stored in the same database? That would mean that shared object= s (e.g. contacts, hosts, etc.) would have to be written multiple times. Tha= t seems less than ideal. --_000_CDE63F2151447jgouldverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Seth,

You might want to post this to the Internet Registration Escrow (IRE) = list ( https://w= ww.ietf.org/mailman/listinfo/ire ).  My understanding is that= the deposits are per-TLD and not per registry operator.  

-- 

 

JG

 

 

James Gould

= Principal Software Engineer

j= gould@verisign.com

=  

= 703-948-3271 (Office)

= 12061 Bluemont Way

= Reston, VA 20190

VerisignInc.com


From: Seth Goldman <sethamin@google.com>
Date: Tuesday, June 18, 2013 4:42 P= M
To: EPP Provreg <provreg@ietf.org>
Subject: [provreg] Are escrow depos= it files per-TLD, or per-registry operator?

In the case of a registry operator who operates multiple T= LDs in a single database, are the escrow deposit files intended to be per-T= LD? Or per-registry operator?

My suspicion is that it should be the latter. The entire re= ason for the escrow deposit to exist is to transition to an EBERO in the ev= ent that a registry operator is unable to perform its duties. That could ha= ppen on a per-TLD basis, but it would be a lot more efficient to do it for *all* TLDs that are managed by that r= egistry operator.

So if that is the case, what are we to make of the escrow d= eposit file naming convention?

Files will be named according to the following convention:
 
{gTLD}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext} where:
5.1 {gTLD} is replaced with the gTLD name; in case of an IDN-TLD, the ASCII= -compatible form
(A-Label) must be used;

If there is a single escrow file with multiple TLDs embedde= d in it, what would you use for "{gTLD}"? Is the assumption that = all TLDs will be stored in totally separate databases? Or that they should = be written to separate files, even if stored in the same database? That would mean that shared objects (e.g. contacts, = hosts, etc.) would have to be written multiple times. That seems less than = ideal.
 --_000_CDE63F2151447jgouldverisigncom_-- --_004_CDE63F2151447jgouldverisigncom_ Content-Type: image/png; name="8A7A655D-9ED0-4D38-898D-E9E8B754666E[6].png" Content-Description: 8A7A655D-9ED0-4D38-898D-E9E8B754666E[6].png Content-Disposition: inline; filename="8A7A655D-9ED0-4D38-898D-E9E8B754666E[6].png"; size=4109; creation-date="Tue, 18 Jun 2013 20:47:25 GMT"; modification-date="Tue, 18 Jun 2013 20:47:25 GMT" Content-ID: <330C1C8F-95EE-4160-BE78-8271CD0967B2> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CDE63F2151447jgouldverisigncom_-- From ajs@anvilwalrusden.com Tue Jun 18 13:49:28 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA31C21F9A93 for ; Tue, 18 Jun 2013 13:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOF1NmSyUJrt for ; Tue, 18 Jun 2013 13:49:23 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC7921F9A91 for ; Tue, 18 Jun 2013 13:49:23 -0700 (PDT) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 3BC368A031 for ; Tue, 18 Jun 2013 20:49:12 +0000 (UTC) Date: Tue, 18 Jun 2013 16:49:03 -0400 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20130618204903.GB31925@mx1.yitter.info> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Are escrow deposit files per-TLD, or per-registry operator? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:49:29 -0000 On Tue, Jun 18, 2013 at 04:42:13PM -0400, Seth Goldman wrote: > My suspicion is that it should be the latter. The entire reason for the > escrow deposit to exist is to transition to an EBERO in the event that a > registry operator is unable to perform its duties. That could happen on a > per-TLD basis, but it would be a lot more efficient to do it for *all* TLDs > that are managed by that registry operator. But a single file would entail that all the registries move _en masse_ to a single new operator -- an assumption that is pretty brittle. If you have one escrow file per escrowed zone, you can always put them together. If you have one big file, it's work to take them apart. Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From cbbrowne@afilias.info Tue Jun 18 13:51:48 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EDB11E8100 for ; Tue, 18 Jun 2013 13:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsniFW5QrtoS for ; Tue, 18 Jun 2013 13:51:42 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id D117521F9ABC for ; Tue, 18 Jun 2013 13:51:32 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1Up2sG-0007E8-3T for provreg@ietf.org; Tue, 18 Jun 2013 20:51:32 +0000 Received: from mail-ob0-f179.google.com ([209.85.214.179]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1Up2sF-0001r9-6N for provreg@ietf.org; Tue, 18 Jun 2013 20:51:32 +0000 Received: by mail-ob0-f179.google.com with SMTP id xk17so5168903obc.10 for ; Tue, 18 Jun 2013 13:51:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=kY/LRpIy6Ui0QXuAJ6ahqgPghDB/uIeYmev6XUHx1+c=; b=l86RwVD3TRiwzvFpnIKw8Ueg+hZaGCH/NRCC4rHWN1XFgyQCltSJyNyFzjY3RIBi3n oz0d+WVqbsKF1lqaTzIIolIb08/DHA2YMdoW3rf3Ze3OVNhMoITJHuSH0MF+NeqwiPE7 jIPxnAs0qglvfMbj32h5TnUM++ygy5vZHmaqUZc/rl7XDnlyo0YANg9qdNiuO6/dhvcD If2Htu8RyXtFw/hHVDwJVZPd201c1v30amN2qpyRKNb25pb0kag60CQcdpy7BnKu9Y5k QMUsU6tUYLnos5hiDlptlpSi6mJmG9jDVFh1y0gPTarWYZu6wDqyjl9kKC6bdqWMePs6 1t7A== X-Received: by 10.60.47.227 with SMTP id g3mr11082200oen.125.1371588686477; Tue, 18 Jun 2013 13:51:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.47.227 with SMTP id g3mr11082195oen.125.1371588686416; Tue, 18 Jun 2013 13:51:26 -0700 (PDT) Received: by 10.76.21.20 with HTTP; Tue, 18 Jun 2013 13:51:26 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Jun 2013 16:51:26 -0400 Message-ID: From: Christopher Browne To: Seth Goldman Content-Type: multipart/alternative; boundary=001a11c30a1e6ea0c704df73e068 X-Gm-Message-State: ALoCoQkNwBSKrzspMSZgdK028tTIdWCHo47zAolfjjKO7hQOAdhbJtfgIG8LNX4mOOVRK04oMAC6rI7JONXpHEPRB/zsaotop5isW86xG+tcOJkqU4nWhYgVTRp++F0Zf3RYf2E6xzdx Cc: EPP Provreg Subject: Re: [provreg] Are escrow deposit files per-TLD, or per-registry operator? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:51:48 -0000 --001a11c30a1e6ea0c704df73e068 Content-Type: text/plain; charset=ISO-8859-1 Those seem like pretty good questions. That said, while an aspect of efficiency could be gained by avoiding the need to write out shared objects multiple times, this involves the assumption that all of the TLDs would be passed on together as a single "block." If there is reason to imagine that the TLDs could be passed on individually, then combining the data would be pretty hazardous, both technically, and, I'd think more hazardous, legally. --001a11c30a1e6ea0c704df73e068 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Those seem like pretty good questions.

That said, while an aspect of efficiency could be gained by avoiding = the need to write out shared objects multiple times, this involves the assu= mption that all of the TLDs would be passed on together as a single "b= lock."

If there is reason to imagine that the TLDs= could be passed on individually, then combining the data would be pretty h= azardous, both technically, and, I'd think more hazardous, legally.
--001a11c30a1e6ea0c704df73e068-- From brunner@nic-naa.net Tue Jun 18 13:55:41 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AE521E8054 for ; Tue, 18 Jun 2013 13:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S02Z68jKTf20 for ; Tue, 18 Jun 2013 13:55:36 -0700 (PDT) Received: from wampumpeag.net (unknown [65.99.1.131]) by ietfa.amsl.com (Postfix) with ESMTP id D08CD21F962D for ; Tue, 18 Jun 2013 13:55:35 -0700 (PDT) Received: from abalone.local ([67.42.198.88]) by wampumpeag.net (8.14.7/8.14.7) with ESMTP id r5IKtXb6055309 for ; Tue, 18 Jun 2013 16:55:33 -0400 (EDT) (envelope-from brunner@nic-naa.net) Message-ID: <51C0C944.6080008@nic-naa.net> Date: Tue, 18 Jun 2013 13:55:32 -0700 From: Eric Brunner-Williams Organization: wampumpeag User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: provreg@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Are escrow deposit files per-TLD, or per-registry operator? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ebw@abenaki.wabanaki.net List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:55:42 -0000 On 6/18/13 1:42 PM, Seth Goldman wrote: > In the case of a registry operator who operates multiple TLDs in a > single database, are the escrow deposit files intended to be per-TLD? > Or per-registry operator? > > My suspicion is that it should be the latter. The entire reason for > the escrow deposit to exist is to transition to an EBERO in the event > that a registry operator is unable to perform its duties. That could > happen on a per-TLD basis, but it would be a lot more efficient to do > it for *all* TLDs that are managed by that registry operator. > > So if that is the case, what are we to make of the escrow deposit file > naming convention? > While sensible, at no point during the multi-year struggle to impart sense into the DAG was any argument for any means of recognizing two or more applications "communicated" (had same applicants, used same backends, liked the same wine, ...) successful. I wouldn't gamble that escrow can be "bundled" or that any other operational activity that exists in contractual form can be, from insurance to continuity instrument to ... failover flavor preference. Failure is a property of the registry operator, which in our refined parlance means the two or three clowns who managed to get a piece of paper past ICANN legal, who may run out of money or be found to be sudden guests of the United States (my favorite form of incapacity, see the Brothers Elashi and the .iq saga, at a google near you), or encounter some other trigger condition. YMMV, of course. Eric From michael@mwyoung.ca Tue Jun 18 13:59:02 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFEEC21E80A5 for ; Tue, 18 Jun 2013 13:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xsx6ubxRAE+C for ; Tue, 18 Jun 2013 13:59:01 -0700 (PDT) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5524A21E809A for ; Tue, 18 Jun 2013 13:59:01 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id l10so5716576oag.31 for ; Tue, 18 Jun 2013 13:59:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=Jw0a1M0VFqfWcp5L3kwaYXhRMQ3HIekugsjMbKAw96E=; b=biOKenx1Q9bTfkocUtDS+0jtsxPkOCrm5SHNWup2pMvNYKyYxeR5EvNtAjHFwYNIUe 1i2TWy71CzZv9r/X7sa1Ny6R2zqEUNCGon0tntb/gJH29XvD8J+n7K7QyOy/LcVrS67r 1Z4wZ86BcNNqzqRJ2Pa0s6B054Q7LwNTTUohbhqgo6J+YV8IsdyJa2wsYPKUw3yHtELl dC5lMSi6I36AZFynlHbAhwiO2BZN61GOvsuqmodX2EhanKi0l3KlJMJzMRbLkVv5ibFA Lr1MU4UIxKihzrwslPN+teVTezmTPhAc4UR/hn0vSI+9pOedWB2scpTZ7RvUUsYFahMk T+ng== X-Received: by 10.182.142.104 with SMTP id rv8mr9443961obb.3.1371589140306; Tue, 18 Jun 2013 13:59:00 -0700 (PDT) Received: from [172.16.1.20] (CPEf87b8c0c1175-CM78cd8ece2635.cpe.net.cable.rogers.com. [173.32.228.181]) by mx.google.com with ESMTPSA id x10sm17051662obw.13.2013.06.18.13.58.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 13:58:59 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_91D47CB6-E658-4BD8-AF8F-09DC5AB58DFB" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: MICHAEL YOUNG In-Reply-To: <20130618204903.GB31925@mx1.yitter.info> Date: Tue, 18 Jun 2013 16:58:56 -0400 Message-Id: <31B3913C-1F75-46BF-A328-5078792D925C@mwyoung.ca> References: <20130618204903.GB31925@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQnVIhrnZzOs87w65AWUyIbRyF9OryqR9laHjALq9CY2VmPBc6bFGRc/QeasXVzBKxW3kEH1 Cc: provreg@ietf.org Subject: Re: [provreg] Are escrow deposit files per-TLD, or per-registry operator? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:59:02 -0000 --Apple-Mail=_91D47CB6-E658-4BD8-AF8F-09DC5AB58DFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I agree with Andrew on this. -Michael Young On 2013-06-18, at 4:49 PM, Andrew Sullivan = wrote: > On Tue, Jun 18, 2013 at 04:42:13PM -0400, Seth Goldman wrote: >> My suspicion is that it should be the latter. The entire reason for = the >> escrow deposit to exist is to transition to an EBERO in the event = that a >> registry operator is unable to perform its duties. That could happen = on a >> per-TLD basis, but it would be a lot more efficient to do it for = *all* TLDs >> that are managed by that registry operator. >=20 > But a single file would entail that all the registries move _en masse_ > to a single new operator -- an assumption that is pretty brittle. If > you have one escrow file per escrowed zone, you can always put them > together. If you have one big file, it's work to take them apart. >=20 > Best, >=20 > A >=20 > --=20 > Andrew Sullivan > ajs@anvilwalrusden.com > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg MICHAEL YOUNG michael@mwyoung.ca --Apple-Mail=_91D47CB6-E658-4BD8-AF8F-09DC5AB58DFB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii ajs@anvilwalrusden.com> = wrote:

On Tue, Jun 18, 2013 at 04:42:13PM -0400, Seth Goldman = wrote:
My suspicion is that it should be = the latter. The entire reason for the
escrow deposit to exist is to = transition to an EBERO in the event that a
registry operator is = unable to perform its duties. That could happen on a
per-TLD basis, = but it would be a lot more efficient to do it for *all* TLDs
that are = managed by that registry operator.

But a single file = would entail that all the registries move _en masse_
to a single new = operator -- an assumption that is pretty brittle.  If
you have = one escrow file per escrowed zone, you can always put them
together. =  If you have one big file, it's work to take them = apart.

Best,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com
_____= __________________________________________
provreg mailing = list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg<= br>




MICHAEL = YOUNG




= --Apple-Mail=_91D47CB6-E658-4BD8-AF8F-09DC5AB58DFB-- From michael@mwyoung.ca Tue Jun 18 14:01:34 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F133321E8092 for ; Tue, 18 Jun 2013 14:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nicv6Lo9xa9H for ; Tue, 18 Jun 2013 14:01:31 -0700 (PDT) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 81FC921E8054 for ; Tue, 18 Jun 2013 14:01:31 -0700 (PDT) Received: by mail-oa0-f46.google.com with SMTP id h1so5657189oag.5 for ; Tue, 18 Jun 2013 14:01:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=pUQfTp9PTKHfp5u1r4I2pIbESIk+Qlu0f10vxMj8GC4=; b=ThZ39oIB18CMOMOcw1xHLeRgrf88PSoEgh3IBFcUekT9vVqPxRzHGAEywQUX68iOUh JWfCERsAzKukIIiJ8qNHVlBbjquTHRMw8fiSymo53HUTsZJ1WmQQg6juFx+CApmcTLXf VED5yp+8bhxXcLtr9hmJYa+uvFGsw0U78lBIcpu8a13gUbOC6rNX2Uqs1skyOgbthFbm FXYUlOdBA33VwbRno8ZSGVrva7LnRdv/PO8S5O1iBP+Qds+sLWB6EUOh9IyeD82Pp95/ uAEFFOv2z+c9aON8fa46YSYTo0tA0fjQYd/YyrV0YbklhI32s35dGlWw/KMPhhDE8oIQ e0hg== X-Received: by 10.60.124.18 with SMTP id me18mr13338984oeb.100.1371589291060; Tue, 18 Jun 2013 14:01:31 -0700 (PDT) Received: from [172.16.1.20] (CPEf87b8c0c1175-CM78cd8ece2635.cpe.net.cable.rogers.com. [173.32.228.181]) by mx.google.com with ESMTPSA id o4sm23692914obl.7.2013.06.18.14.01.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 18 Jun 2013 14:01:29 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_36DCB3B3-DAED-42DF-869F-B5211E386B60" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: MICHAEL YOUNG In-Reply-To: Date: Tue, 18 Jun 2013 17:01:26 -0400 Message-Id: <68BBA3AB-A8BE-413D-B84E-15456E97C8A1@mwyoung.ca> References: To: Christopher Browne X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQk7BP8nA22EYE4qzUrkY5ZnffAVojy592Az+12Crq4HofTeDPbYgIt/sOlOTwvEWa+jI8mn Cc: EPP Provreg Subject: Re: [provreg] Are escrow deposit files per-TLD, or per-registry operator? X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 21:01:34 -0000 --Apple-Mail=_36DCB3B3-DAED-42DF-869F-B5211E386B60 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Sure Chris, an example would be what if one TLD has a set of extensions = the other one doesn't? Makes a single block much more complicated to = manage. Also what if a registry operator uses the escrow file as part of their = transition efforts for a single TLD out of several in a non-emergency = situation? (As in a sale,....) -Michael On 2013-06-18, at 4:51 PM, Christopher Browne = wrote: > Those seem like pretty good questions. >=20 > That said, while an aspect of efficiency could be gained by avoiding = the need to write out shared objects multiple times, this involves the = assumption that all of the TLDs would be passed on together as a single = "block." >=20 > If there is reason to imagine that the TLDs could be passed on = individually, then combining the data would be pretty hazardous, both = technically, and, I'd think more hazardous, legally. > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg MICHAEL YOUNG michael@mwyoung.ca --Apple-Mail=_36DCB3B3-DAED-42DF-869F-B5211E386B60 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 cbbrowne@afilias.info> = wrote:

Those seem like pretty good = questions.

That said, while an aspect of = efficiency could be gained by avoiding the need to write out shared = objects multiple times, this involves the assumption that all of the = TLDs would be passed on together as a single "block."

If there is reason to imagine = that the TLDs could be passed on individually, then combining the data = would be pretty hazardous, both technically, and, I'd think more = hazardous, legally.
_______________________________________________
provreg mailing = list
provreg@ietf.org
https://www.ietf.= org/mailman/listinfo/provreg




MICHAEL = YOUNG




= --Apple-Mail=_36DCB3B3-DAED-42DF-869F-B5211E386B60-- From sethamin@google.com Thu Jun 20 09:04:45 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDB821F9D88 for ; Thu, 20 Jun 2013 09:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObGly8buJ8lC for ; Thu, 20 Jun 2013 09:04:40 -0700 (PDT) Received: from mail-pd0-f174.google.com (mail-pd0-f174.google.com [209.85.192.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7B03621F9A7C for ; Thu, 20 Jun 2013 09:04:40 -0700 (PDT) Received: by mail-pd0-f174.google.com with SMTP id 10so6353905pdc.5 for ; Thu, 20 Jun 2013 09:04:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=chE2XQTXbcRPWUTdzhFojKGbqrv4aKHC1DmC368H650=; b=p1LUOfJkW2skPjN5yfLjReaNCWOF+6sKJnZng56ehtvbrDnRKbBpyMajAIJ5h26d3e P6nOoIRGx9fWl4PF/dzQSdoKbGMLF66+x1cxiUlolgVgk2auDnkZo0X7WmR/iDbt8f+1 WfIOO4wpgTzYh82bpi2Lt1mFET2Cmc2svxz9WDkuAuq5h1K8/FcYTWKT4H6B8G7661W+ B+JdTB7DfWL+r9zUlooLslhJQ7nF4P0gFn8yelTibKz1oy9HaahzLxqLBia/fSA4o6fC eBHWLs0RW2uwNaamDnQDWLf5wW3+vaHXDJQKnW2ldkJkKqhW2EtJa7WEfYZw3opE3LGx hp1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=chE2XQTXbcRPWUTdzhFojKGbqrv4aKHC1DmC368H650=; b=RpWE0IPB+UAStneOEgv4Ksy19NjVmZOmpHhiG1BhRkzv61C0RNTPuVKAAJKTtMDm2t 6PG6pQoowpUta6lmp0+ydyCRumez8OLFulBo7bzmn8bt6yVh8TAKg8Fqs+974TXai3h1 qjl27bQUqA3Ist5GWNgr/bvb9o2gJ+zOYJf+e9v7mGiMccuFImVqJm04JTsJcyR4aO0b QDJ5GwDj5gqtd+4i9P4P3UgLrO0Q5m2u+mzDi6Lge3bM4/OCAMF1TUNuZ7NMPMkp7KEi bOtla12l1b3TBJQMMMa/1JwT8ub+EAGhz73ZnrIO4L4/KJ59OB0qxy7Pf+dO6ZUDi3kk 1Irw== MIME-Version: 1.0 X-Received: by 10.66.25.10 with SMTP id y10mr12160656paf.96.1371744280198; Thu, 20 Jun 2013 09:04:40 -0700 (PDT) Received: by 10.70.27.69 with HTTP; Thu, 20 Jun 2013 09:04:40 -0700 (PDT) Date: Thu, 20 Jun 2013 12:04:40 -0400 Message-ID: From: Seth Goldman To: EPP Provreg Content-Type: multipart/alternative; boundary=bcaec52bec178b6fb704df981af5 X-Gm-Message-State: ALoCoQmiTHr+BSbSdl7sDD45IML5Q2n4Zju8Zy/QAZzlpeyivI0pZCoBB7lg5SKQ0CtEsk9HN653ZeOlDCL5KzYqu0QBhfojeCqPdaj0bjjqi4px5KeArUby1dLa1Ptl0mad7qsHEVUplwGULDDB8DwI43iQBrefIzEhCzLz49CWrMasoWZkJhc8A4xmltDnhNF1RAn5CRn9 Subject: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:04:45 -0000 --bcaec52bec178b6fb704df981af5 Content-Type: text/plain; charset=ISO-8859-1 What do registrars typically do about contacts sponsored by a different registrar after a domain transfer? This situation seems undesirable, as it prevents the gaining registrar from updating registrant contact information in the future. Do registrars just make a new contact as a matter of course? Or do they try to transfer over the existing contact? The former seems more likely, as the latter will not work if there are other domains with references to that contact object on the losing registrar. --bcaec52bec178b6fb704df981af5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
What do registrars typically do about contacts sponsored b= y a different registrar after a domain transfer? This situation seems undes= irable, as it prevents the gaining registrar from updating registrant conta= ct information in the future. Do registrars just make a new contact as a ma= tter of course? Or do they try to transfer over the existing contact? The f= ormer seems more likely, as the latter will not work if there are other dom= ains with references to that contact object on the losing registrar.
--bcaec52bec178b6fb704df981af5-- From onave@dyn.com Thu Jun 20 09:08:27 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6617F21F9DB9 for ; Thu, 20 Jun 2013 09:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKmxz7HpKbxX for ; Thu, 20 Jun 2013 09:08:23 -0700 (PDT) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9CF21F9DB4 for ; Thu, 20 Jun 2013 09:08:23 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id gd11so4918838vcb.30 for ; Thu, 20 Jun 2013 09:08:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:x-gm-message-state; bh=p6LZBr5urYg0oul3vXmG3ULuLAInmbUlHZAB9RxFI6Q=; b=pChtyNgPcEpJVQL6Ap0LTnOVGzpoO1k6px4e2Ojza2L43aFxUbDMWpCj3MeVnI/M5F hwiC9wpPwVzw8Zo/Eoppt5mHX6gfvQqKWFj+4m5V675eGoVS5Sxmlq/8i+f+gtG9kS1W xWJKher8BJVwbib+vaQuyqMuQbI6M0D+kbWbaFMFHKQbIgNaEo1U0nkw6lJ6N3qpWwIP /b8UmY8w8mFxHxW9Fv2G9nnAOwG+Q7P8N16Nbw4u87Qj2CLUVw++T7L/USi3+d1KLjfp Q4fqkTNNB0BZIn9bXNegb1Ndl9PmS1K0mjKTSP97f2hgysPijXa7wKz5r19X32DXsvrY 3rXA== X-Received: by 10.221.67.9 with SMTP id xs9mr3183451vcb.12.1371744502488; Thu, 20 Jun 2013 09:08:22 -0700 (PDT) Received: from ?IPv6:2600:200f:1:30:a022:3277:7abe:2add? ([2600:200f:1:30:a022:3277:7abe:2add]) by mx.google.com with ESMTPSA id kz18sm966421vdb.13.2013.06.20.09.08.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 09:08:21 -0700 (PDT) Message-ID: <51C328F3.7020301@dyn.com> Date: Thu, 20 Jun 2013 12:08:19 -0400 From: Ofer Nave User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: provreg@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020109080709090505060203" X-Gm-Message-State: ALoCoQnOKiRQrpnX//GWbZEAxNAts1nXnbGh0gqWwfTkO1DT8ZUJVUB5hXrr7hR5rijJxim96KOa Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:08:27 -0000 This is a multi-part message in MIME format. --------------020109080709090505060203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As an EPP noob, I'm confused by the same thing (being able to 'transfer' a contact object). I get the point of transferring a domain name because it represents ownership, like a title or deed. It can only be 'owned' by a single registrar at a time. But a contact is merely a data structure. Shouldn't contacts and hosts just be copied automatically by the gaining registrar in the case of a domain transfer? What does it mean to 'transfer' a contact, as opposed to merely copying the data? -ofer On 06/20/2013 12:04 PM, Seth Goldman wrote: > What do registrars typically do about contacts sponsored by a > different registrar after a domain transfer? This situation seems > undesirable, as it prevents the gaining registrar from updating > registrant contact information in the future. Do registrars just make > a new contact as a matter of course? Or do they try to transfer over > the existing contact? The former seems more likely, as the latter will > not work if there are other domains with references to that contact > object on the losing registrar. > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg --------------020109080709090505060203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
As an EPP noob, I'm confused by the same thing (being able to 'transfer' a contact object).

I get the point of transferring a domain name because it represents ownership, like a title or deed.  It can only be 'owned' by a single registrar at a time.  But a contact is merely a data structure.  Shouldn't contacts and hosts just be copied automatically by the gaining registrar in the case of a domain transfer?  What does it mean to 'transfer' a contact, as opposed to merely copying the data?

-ofer

On 06/20/2013 12:04 PM, Seth Goldman wrote:
What do registrars typically do about contacts sponsored by a different registrar after a domain transfer? This situation seems undesirable, as it prevents the gaining registrar from updating registrant contact information in the future. Do registrars just make a new contact as a matter of course? Or do they try to transfer over the existing contact? The former seems more likely, as the latter will not work if there are other domains with references to that contact object on the losing registrar.


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

--------------020109080709090505060203-- From cbbrowne@afilias.info Thu Jun 20 09:09:41 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C152221F9DB7 for ; Thu, 20 Jun 2013 09:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMOLU+KhgKzc for ; Thu, 20 Jun 2013 09:09:36 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [66.199.183.4]) by ietfa.amsl.com (Postfix) with ESMTP id EC62921F9DB4 for ; Thu, 20 Jun 2013 09:09:35 -0700 (PDT) Received: from ms5.on1.afilias-ops.info ([10.109.8.9] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.72) (envelope-from ) id 1UphQV-00044z-4Z for provreg@ietf.org; Thu, 20 Jun 2013 16:09:35 +0000 Received: from mail-we0-f169.google.com ([74.125.82.169]) by smtp.afilias.info with esmtps (TLSv1:RC4-SHA:128) (Exim 4.72) (envelope-from ) id 1UphQV-0007cQ-45 for provreg@ietf.org; Thu, 20 Jun 2013 16:09:35 +0000 Received: by mail-we0-f169.google.com with SMTP id n57so5666358wev.28 for ; Thu, 20 Jun 2013 09:09:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=RjirObds3gMVWOVDBcvWKvLvA88o02A/DqDlPQ1q1QI=; b=BtE143dXunaxnAXsNpp7jLkGEa+JncSAytmRqPDVETPFgBFmwPh50qpxZ2yP78UVRJ F+qKX+wD4oXJVHHjENQ9/XKs0t1gwdEyJbxHFP0jLutO3t6G4vfqG/oUFQZGIbw811ai a224k9vnP9RNkgqn7FCEIlaprccnsITEVeBwhjkpfGaColI6tD9YyicmBIBCq7yCH2ae pPrVoOxV5yJNCIHMd3vqFhHO58Xm/32B7pAaNnI83GnzD4Tn5MElymkDz3ZXQ7cjoTty SjV4j0M7iw06QGp4pD422LIyVRkWTR3I3JQUniOntbkvzX5uEhaO4x7jPq8+14XNT95a SQQg== X-Received: by 10.180.182.229 with SMTP id eh5mr5920043wic.63.1371744569295; Thu, 20 Jun 2013 09:09:29 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.182.229 with SMTP id eh5mr5920039wic.63.1371744569231; Thu, 20 Jun 2013 09:09:29 -0700 (PDT) Received: by 10.194.88.99 with HTTP; Thu, 20 Jun 2013 09:09:29 -0700 (PDT) In-Reply-To: References: Date: Thu, 20 Jun 2013 12:09:29 -0400 Message-ID: From: Christopher Browne To: Seth Goldman Content-Type: multipart/alternative; boundary=089e0163491ec59d1e04df982bb7 X-Gm-Message-State: ALoCoQnYcjnnKwCxHQJb+vMISOgUboZR/+65L14h+7M+t5b9DZVPXceq60ZImo6XV4b3qiKLIh10/7Ffc385x6m2QGev8uALc/REHUHci12i9Jd7foFkrkRGGvdmD6CKPydnZYFxUdTT Cc: EPP Provreg Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:09:41 -0000 --089e0163491ec59d1e04df982bb7 Content-Type: text/plain; charset=ISO-8859-1 It's pretty common that the old contacts get left to moulder away, and the registrar generally creates new contacts for their newly sponsored domain. It seems remarkably common for old contacts to get left behind for a lot of reasons; it appears some registrars create fresh contacts (using UUID-like logic; there are likely not strictly enough bits in the clientID value to actually use real UUIDs) every time *any* contact update takes place. --089e0163491ec59d1e04df982bb7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
It's pretty common that the old contacts get left to m= oulder away, and the registrar generally creates new contacts for their new= ly sponsored domain.

It seems remarkably common fo= r old contacts to get left behind for a lot of reasons; it appears some reg= istrars create fresh contacts (using UUID-like logic; there are likely not = strictly enough bits in the clientID value to actually use real UUIDs) ever= y time *any* contact update takes place.
--089e0163491ec59d1e04df982bb7-- From JGould@verisign.com Thu Jun 20 09:11:27 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B91FE21F9C4D for ; Thu, 20 Jun 2013 09:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.732 X-Spam-Level: X-Spam-Status: No, score=-5.732 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9OY9NiWUHy0 for ; Thu, 20 Jun 2013 09:11:22 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by ietfa.amsl.com (Postfix) with ESMTP id BD3B621F9C65 for ; Thu, 20 Jun 2013 09:11:21 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKUcMpqdv2cSX+04JqYsneVXMfbvslNDiy@postini.com; Thu, 20 Jun 2013 09:11:22 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id r5KGBKgf007479 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Jun 2013 12:11:20 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 20 Jun 2013 12:11:20 -0400 From: "Gould, James" To: Seth Goldman , EPP Provreg Thread-Topic: [provreg] Contacts after a Domain Transfer Thread-Index: AQHObc/kLcfugeRfBUWmJxBht82Y9Jk+xesA Date: Thu, 20 Jun 2013 16:11:19 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.173.152.4] Content-Type: multipart/related; boundary="_004_CDE8A0CB518DEjgouldverisigncom_"; type="multipart/alternative" MIME-Version: 1.0 Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:11:27 -0000 --_004_CDE8A0CB518DEjgouldverisigncom_ Content-Type: multipart/alternative; boundary="_000_CDE8A0CB518DEjgouldverisigncom_" --_000_CDE8A0CB518DEjgouldverisigncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Seth, The Registrars typically reset the contacts on the domains after the domain= transfer. The contact objects sponsored by the gaining registrar could al= ready exist, so creating new contact objects might not be necessary. A cont= act transfer could be done, but is not likely. -- JG [cid:2B62FA9D-6B65-4554-B878-7E670B759976] James Gould Principal Software Engineer jgould@verisign.com 703-948-3271 (Office) 12061 Bluemont Way Reston, VA 20190 VerisignInc.com From: Seth Goldman > Date: Thursday, June 20, 2013 12:04 PM To: EPP Provreg > Subject: [provreg] Contacts after a Domain Transfer What do registrars typically do about contacts sponsored by a different reg= istrar after a domain transfer? This situation seems undesirable, as it pre= vents the gaining registrar from updating registrant contact information in= the future. Do registrars just make a new contact as a matter of course? O= r do they try to transfer over the existing contact? The former seems more = likely, as the latter will not work if there are other domains with referen= ces to that contact object on the losing registrar. --_000_CDE8A0CB518DEjgouldverisigncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <03BD67477D9EBC49B17A702E47C12651@verisign.com> Content-Transfer-Encoding: quoted-printable
Seth,

The Registrars typically reset the contacts on the domains after the d= omain transfer.  The contact objects sponsored by the gaining registra= r could already exist, so creating new contact objects might not be necessa= ry. A contact transfer could be done, but is not likely.  

-- 

 

JG

 

 

James Gould

= Principal Software Engineer

j= gould@verisign.com

=  

= 703-948-3271 (Office)

= 12061 Bluemont Way

= Reston, VA 20190

VerisignInc.com


From: Seth Goldman <sethamin@google.com>
Date: Thursday, June 20, 2013 12:04= PM
To: EPP Provreg <provreg@ietf.org>
Subject: [provreg] Contacts after a= Domain Transfer

What do registrars typically do about contacts sponsored b= y a different registrar after a domain transfer? This situation seems undes= irable, as it prevents the gaining registrar from updating registrant conta= ct information in the future. Do registrars just make a new contact as a matter of course? Or do they try to transfer = over the existing contact? The former seems more likely, as the latter will= not work if there are other domains with references to that contact object= on the losing registrar.
 --_000_CDE8A0CB518DEjgouldverisigncom_-- --_004_CDE8A0CB518DEjgouldverisigncom_ Content-Type: image/png; name="8A7A655D-9ED0-4D38-898D-E9E8B754666E[33].png" Content-Description: 8A7A655D-9ED0-4D38-898D-E9E8B754666E[33].png Content-Disposition: inline; filename="8A7A655D-9ED0-4D38-898D-E9E8B754666E[33].png"; size=4109; creation-date="Thu, 20 Jun 2013 16:11:19 GMT"; modification-date="Thu, 20 Jun 2013 16:11:19 GMT" Content-ID: <2B62FA9D-6B65-4554-B878-7E670B759976> Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAEkAAABACAIAAADZHs1DAAAP1ElEQVRoBe2aa3CU1RnHN3vLJtmQ hEtiwlUBtZUUCiU6tU7wVhinjOB0xmJnFIdpO1Y6DY586Iwdo36gLc4Iip3pVAL9IKjTDnhDEEWC 1GoICHLRctEkXHIPuZHr7qa/c553T152N9lsNvnWM5nDec97Ls//+T+X854lZWBgwDFuRRaXOiUl hX2kHrcNr1vYfd1T0g/ACIVCQV0CgQD/8miwOZ1Ol8vldrupKTyOK9QU2ThpUA4w9Pf39/X19fT0 UCsYYHA6QcLiYKCwF2MEMNh8Pp/X6/V4PAxOXoDoFcYAG7ICplsXNvClpSFvipAimGy1wQmrMgV4 aUzxekEbLV8yPUlhE66u6YJkqT6fMjKDyjRs2GgaeNKA587OTqZnZGSMLYejx4biEautrQ3eUlNT LUiCx6AyjWHhAbKrqwuEwMNQxYyTYUzmjhIbboMo7e3tyIwoMYA5nZ+duXiyur6ju88u5ZL5s+ff mJ+TmUan4JUGNVbQ2tqKNvx+PwTaZ42uPRpseBeoYMygUvRoijp7AnuPXdhz9PyeyvPI7khxqtoU yTcDofk35j1674LH7luY7U8zVsoo2qgMc5gwYQIeaOaNrpEwNoCBqraujgBALDeoOnr6X9t/4rX9 x9t7gg6Xx+F0K1QEQOBRFKoBVYdCjoGgI6T+MtO9j9+74Nlf3gNChhiQHR0dwMvKykoSXmLYMEUY u3T5MoyxMZEDbJTK81fWlR242NrrcHsdToBpSBZpsKeps0gDocYWDDhC6i8zzbO9ZOWKH38/Ah5K hL1kjDMBbMQMDKa6pgaE6enpggp4r+z5cvOeLx0en6bLpRkTbIKKWjGnijoCgQ3qdB3sdwR6FcJg 8NF7Crc99XNeG/ZQIvkQ3xt1bhgpNrYhlMFYY0NDVna2Bczp/MPrh3dVVjncAHOrvxSwuSw3U3SF SVPIxDKpBVuYQOABMtg3f+aUA39aY/fApqYmLB89CmBZY+T1SA8EcIWb1dfXk8QIaFIUsKM1Dk+a w+1xuLQ1Ag9s1p9uC9rBTk2sUoRLq8Ojp6cy/UR100MvvK41oPkdGMjJySF3svXI8dhHjggbSDhD ED8wSxgTYLsqLihgbsRCULBp3gghBobyN5AY33NalKoeuA2rgInYs1rHU37m4rq/vW/gsReZk63Z 0S70CNsjwiakNTU2etxuAXax5dpf3juuuBJgFiQtPdgUKv3n1DZpPdrawFPDwvBoW/C8L79bceD4 eQOPcELMHB118bHhab29vYq0UIhjvGB77p+VHeRk7MpCIn5lgobRrHY5noCnQgrD5JX5sJJOPZ0Y q/h3rdn0NpsaePgbAkiPWXckjfjfOJytMHrcmngltnGsqqmyqllZUYozK82z4MY8tZNYmtnT6T5+ saWtV1DpXuARRYLB4ltyVWw0hZRA4VDS1Xfiu3pe1TR3vLDz4B9XLSGEAIlw0tzcTJ1oPoiPDXto uXoVzfkzM/kyQ4y/f3JW0QVpig3H7vXLJfkqEW3l4OlLd/95n7JbU0KB4rkTDz6z3HTYGyVlH5+o alTjQ6FtHx575hfFvAUeXodaESNRbHFsErWRQxsaGpRBpqRQX2ru/LKmRScxZZBtnd0lr31oF9G0 l9w2rfjmXJWppdDo79n+xL1mgL1RVd+6+f1jWmUq9dc0tb/z+TfsTmEYB2jEkLZ91vDtONgwQhgj ZavPaf1N/enZegUM3uTP7f3Hga8OnqyKuc323xQ7OH9ICQaefWjRrCkTYo5c/fK7yshlTXVkc739 +RlGanQDREvEEI+IOT1mZxxsBH0WlfO+uioIhQ6dbdSuhffrUI5Aqf7SNz6NuTpInl2xQHlXKJDl CZU8sCDmsN1fnC0/16wCiVqTU6jS3cGvqoUoakk87B9z+lCdcbChKoAJY7SBV9PUobMTE3VwQ9Me X/nXtds/Ph5zj5JlhVk+J2erTY/+JDvDF3tM2ceaNI41kjzw5BTMsrWzx8DD8caBt76+YEDZlaYt 1N4bUqo1fyBE39700rf+09rZHS16dkbqplWL5xf4Vy9Rp+HoUvrG4eo2/emgzmgUWVzBO/Fdrdgk vZjlGPPG0nClCVP1uXpIE6qtPKVBOtF6dUv3pt2faeEiK1Bt/+39kb36ufVaz6YPz6jEDf+WvvQL Mor+WhVsSozwfVnMdWJ2DpcDZF0MElj9+kKuvZuERdEJ16p1B/nAk/bcv46svn/RrLxs3XVdBaUp KzYoR7UX1IS7qg+I62+BLALVUGSQGQbkyM/N129m31jnFukQ3kBoey9bWhuTudWXmze9ZOsQ+aBw 1oN3znOkZTsyJg3+pecQh3QCDFvB4AaqR1NlgZI3IwfG+OGwqdda0xg6qRPjnJGdqveIAKb7OBx6 fG8frR4qH2xaXZzl12diuDJ/KjbiYNevqriytGboMsLooSOq4mBDT1wbWLwFgz5sx3xZyh1B2GaU fDqolJR9FHNn8kHJT2+77rRlH6ew8EUnqHRjYGD65Ex1Ka0Lyk2INJaLg43DzqRJk8BG4WQAgd/L y9ASKFfQsoWl4UH7z4lL7cPkg5k5sdKAAFPLWahYnNuU6ZMnWDFkYEBpOcIt9fbDVHGwyRcUVyNg 6+ntxeVmT0pVx6jBb2cjjd6FtOtJKyk7MFQ+KF35Qz6xBwViHWV++m9wzRD03nXrVIs09tZxUhxk cG68VhxsqIrEkpOdDWPwxi43TUzVt1TcC+g/uyHRxnncqW39rtK3hsgHxbfOn04g1WFJARNcRkE0 9LKh4AOL5hjSerq7EWOMecMSIC0/Px9UwOMzceE0/+QMtyUBcqg7Of5EOK1Jwo/Ht/m9So6/0Zol oVXVNmueBJidNFmKNdVF2LKFsxVvmjTUihhj7G8GG1KyC2dLEN4xw69ub7QEgyAlDIgT6qCijr9R pfTNf7f1Ch4YE1O0kabW5Nqr/+E7b8HfLN50Khh7bMjGVSQ2mX/DDRBHsEKFS+dOSHMNqAO+OgSL 74VVrkxUZUYss/ybuoh8UNXYvnnfaXUNQRkExly9iFpKX10G+p56sMgAQ6EYJGJEKSpORxx/YzZW zlf9DwoL+aUQeHyDp7oGfnW7/nYWNataY6OWBtN0UFm95QP7/qu37FUpnnAKfqWFsEbURI0KfQFs +aJpE/3GIFEoAiTqbEoE+95DtbGHvLy8adOmCTwunublehfc4NWWGWZPtG6FUO1Lbm91c9emdypk WT7DYVJhpoijGkiWjrilDMzLz/j9zxYpLwt7mvwEOZRsw/SPCBs649ejosWLyePA69W/jD6+aNL0 TKe+NhV42j5F/cKeTnelbx6WfKDcT04h8lZpQXOlv+5knUxP8K+/vl9QCTyiCVuPgjQwu0pLS4eB Lq+IKOQWNiDF1dXVYVB89fi8njtmZp6u62rvjfpk5IwiQcXh6O3rr2u6WtXQ/mZFtcKmStjBFHth eMFApjuwY+19N+XlMEIdwrjCCAYzMzPBlmhmU5uwAIqRVtyaKNLS0rJv//5Lly6xGT/iZPj9AYfr xU8bLnaElNzqRkDukuUTUx8TddxT0UUNIHnoqIizKfYEWBBVwdi2J+6bN30SK8tPKMjD3dbEiRPx iLiyxRyQADa0QH6rra19b88efkayw3v3m7aPLnQp0YmB6kssjA1IFKU+/cVptXUUUf7JlZ6y5x/N yN782J1ZGT4FTBcuDjP9fo57OFuiac3gTAAbc/ABAsmV2toP9u418Pgxghh9rrlv29Hmpi5NINjI 4NQUqa0NNWkqPMIbpAVmZPseL5774KJZYVBwlkLQz87Kys3NhTf6ramJ/5MYNtYHHj/ocM1sh+f2 eOTHpM8vdh3+ruPrhm7NXvhT2vqGYbZgA1VozpSMh4tmLl84w6CiweJYfu4UVYj7yQBjs4SxCTzY u3r16ifl5TU1NUigfkB1uVAzJkTIaekOfl3f9d/G3sbOvsZr/U3X1HVLps81c2J6flba3Dz/XTfn FWSnMYW5jBcM5DHaBfn5+FiSjLEdZTTYmCYK5grs9JkzlZWVJAaBh5QKIeda/R9nlNxadgEgtYUG VBqZOqeyXCgEpKkFBfJLt6DVEo6+GiU2NiS04PHYZ0Nj4+lTp85duECXoYIjEgg9/LcfQBqcNpaY TgEXMPhpG1Rgww6ZOOrgEaGG0WOThYRAEDa3tJw/f/7Ct98SCTQfihXT4AGcBApmCXtkTMATCfNy c/kNEVTEesZHyJfMY7LYZG/Uj7eQIQBZ39DAz6tkQvXY3W2HRxuLJeqo+D55MkdwIOGi/IgB4GRg xJw7NthkaTgUkPK5QI3R0kM/AwQkJgcSKKKmCIcxJUu+cyyxGWnEl4BEkTav8CIKCCnSNuPHqTEu 2MZJ1kSXHUvfTXTv8R7/f2zjreHxWT/hS4hkxLhy5QqHNVaYOnUqoX/4pS5wGNCFnE4CHH5wzLfu jS++eOXyZd5t2LBB9tu9e3d5eTk9a9as2bp1a/S0tWvXzp49+9VXXyVZ298iRFFR0dKlS+k0b196 6SUeQcVSJD0znpErV65kRzBs2bKF/mXLlsncYQYzbN26ddQFU6euf/ppGma6SLVz586TJ0/Sj/DO 24uKaFGki8Y5LTFJdt68efrNSCtE37t376lTp6InRABjQEVFxfPPP09+jxgMMKCKFpCBIoNf0fjN YPg4dOiQeTQNVIZRiHW4CwsLd+3axTtIWLx4Mad7oZF+M2HOnDlPPvmkeYxoGGY2btzIK4SOUAqq FVmLi4tXrFgBHlTAMFQbbZm8EskeeeQR5GFBoYKLtoh9GQmSiE4MyojqxpThFzzwtmrVKmNmdmxI tm/fPrOKWI55lAYGKQ2RLOKtPLIFPKBXZALkUGPoRyQBRhupMNdol2MjWImGZ5ZVsQSzZBBDsQex TCSw616MzcyJwIZr8UqYoQHJZqQ00KWoz74OW+BvBkDEFGEJecSm5C3jCwoKpM10BIZ8NBUx1zwq bMYsASa82UljgCjbzIloGKrpR4sYXsQAHn+3di0mhCeLwdODZDt27IjYyEzkrYyxLy6dMoaNkNau LDPXNBQ2Y5Zsb2aaETTQjTFie7+0MZivTp4UoQEW7UIyTJyNNmywkRjIZR2i7WsKIbzFaNmX6McY O3syWGgnRNkB29ehbZ1LltiUjedgRfZxfKoQD0xBOPtbTPShlSulJ1oI+omchEQizZEjR4hV9PCx J+ONl8ojtTAJIWVlZYL8iwrrZtqMkQZeE23/9jGKN4rdNuxteQsnkoLkMTpsogtmiUmDxO6rTEG1 ol2MUFaQGrvCZIyjSidWwDqMp6bYx0e3iaVoLbpfeixsGBI2I3qyR56YihH3jXBiHF0AIBDY7G8J GPDDecDIyiO7SEzCumQX4RC069evh38ZzFsEE6+jjdARg9GF/a0d5/8ActOtScHpPCkAAAAASUVO RK5CYII= --_004_CDE8A0CB518DEjgouldverisigncom_-- From gavin.brown@centralnic.com Thu Jun 20 09:16:00 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9660F21F96EB for ; Thu, 20 Jun 2013 09:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haDJjK44ShLx for ; Thu, 20 Jun 2013 09:15:56 -0700 (PDT) Received: from smtp.centralnic.com (unknown [193.105.170.214]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBBD21F9476 for ; Thu, 20 Jun 2013 09:15:56 -0700 (PDT) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 6F1997203E8; Thu, 20 Jun 2013 16:15:54 +0000 (UTC) Message-ID: <51C32AB8.8050508@centralnic.com> Date: Thu, 20 Jun 2013 17:15:52 +0100 From: Gavin Brown Organization: CentralNic Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Seth Goldman References: In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: EPP Provreg Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:16:00 -0000 We've operated an EPP server since 2005, and have only ever seen a single contact transfer request - which was cancelled shortly after being submitted. Gavin. On 20/06/2013 17:04, Seth Goldman wrote: > What do registrars typically do about contacts sponsored by a different > registrar after a domain transfer? This situation seems undesirable, as > it prevents the gaining registrar from updating registrant contact > information in the future. Do registrars just make a new contact as a > matter of course? Or do they try to transfer over the existing contact? > The former seems more likely, as the latter will not work if there are > other domains with references to that contact object on the losing > registrar. > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > -- Gavin Brown Chief Technology Officer CentralNic Ltd Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From Klaus.Malorny@knipp.de Thu Jun 20 09:33:22 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4DC21F9D9B for ; Thu, 20 Jun 2013 09:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phQ77EBBbHsj for ; Thu, 20 Jun 2013 09:33:15 -0700 (PDT) Received: from kmx10a.knipp.de (clust3c.bbone.knipp.de [195.253.6.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9BC21F9D3E for ; Thu, 20 Jun 2013 09:33:14 -0700 (PDT) Received: from localhost (localhost.bbone.knipp.de [127.0.0.1]) by kmx10a.knipp.de (Postfix) with ESMTP id 50B0245; Thu, 20 Jun 2013 18:33:13 +0200 (MESZ) X-Knipp-VirusScanned: Yes Received: from kmx10a.knipp.de ([127.0.0.1]) by localhost (kmx10a.knipp.de [127.0.0.1]) (amavisd-new, port 10004) with ESMTP id Z-SRKk4LkIQt; Thu, 20 Jun 2013 18:33:04 +0200 (MESZ) Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx10a.knipp.de (Postfix) with ESMTP id 731C244; Thu, 20 Jun 2013 18:33:04 +0200 (MESZ) Received: from [195.253.2.27] (mclane.do.knipp.de [195.253.2.27]) by hp9000.do.knipp.de (@(#)Sendmail version 8.13.3 - Revision 1.000 - 1st August,2006/8.13.3) with ESMTP id r5KGX4VL021357; Thu, 20 Jun 2013 18:33:04 +0200 (MESZ) Message-ID: <51C32EC0.7@knipp.de> Date: Thu, 20 Jun 2013 18:33:04 +0200 From: Klaus Malorny User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0a1 MIME-Version: 1.0 To: provreg@ietf.org References: <51C328F3.7020301@dyn.com> In-Reply-To: <51C328F3.7020301@dyn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:33:22 -0000 On 20/06/13 18:08, Ofer Nave wrote: > As an EPP noob, I'm confused by the same thing (being able to 'transfer' a > contact object). > > I get the point of transferring a domain name because it represents ownership, > like a title or deed. It can only be 'owned' by a single registrar at a time. > But a contact is merely a data structure. Shouldn't contacts and hosts just be > copied automatically by the gaining registrar in the case of a domain transfer? > What does it mean to 'transfer' a contact, as opposed to merely copying the data? > > -ofer > > On 06/20/2013 12:04 PM, Seth Goldman wrote: >> What do registrars typically do about contacts sponsored by a different >> registrar after a domain transfer? This situation seems undesirable, as it >> prevents the gaining registrar from updating registrant contact information in >> the future. Do registrars just make a new contact as a matter of course? Or do >> they try to transfer over the existing contact? The former seems more likely, >> as the latter will not work if there are other domains with references to that >> contact object on the losing registrar. >> Hi, I guess that nearly no registry has implemented the transfers of contacts. The benefit is neglectible and introduces some unwanted side effects. As Seth says, especially, automatically transferring contacts along with the domain is a really bad idea, as these contacts may still be linked with other domains of the losing registrar. Automatic copying of contacts could be done, but this increases the garbage -- without copying, a registrar can theoretically reuse an existing contact for the very same person he has created earlier. Host objects cannot be copied, as the host's name is the (unique) key to the EPP object (contrary to the ID of the contact, which is not part of the content) and therefore no two hosts with the name may exist at the same time. Another registry implementation approach is to use separate object/ID spaces for each registrar. A registrar cannot see/access any object of another registrar at all. In this case, copying is mandatory, or a new set of contacts must be already provided when the domain transfer is initiated (not possible in EPP without extensions). Regards, Klaus From onave@dyn.com Thu Jun 20 09:37:20 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C67021F9E21 for ; Thu, 20 Jun 2013 09:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJc589H+8ji8 for ; Thu, 20 Jun 2013 09:37:19 -0700 (PDT) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 5A85921F9E1C for ; Thu, 20 Jun 2013 09:37:19 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id x14so4868589vbb.34 for ; Thu, 20 Jun 2013 09:37:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=JLHv/8N6OE1qIqakGPGP16Lq6fb8HxceCgNQcS9EQG4=; b=FTsI0GAG9FdripcE1eZ1P+Bt9iLinb3QFwvPk32GVmNEE7PzUMBDTBP4kFJTc3ozF2 2QDd+/oPHK00G5vvy2vg2TKLQAF++qjjP8otMz1vFRoz8qpYpZYZgPt5az0OomI46cJU TTGPxbI/Ld4JWj9N0hyiWfj8VWwq5C95NNWO1fvWR7u5LBqhwlRcUKhQgNfsK6uUCva2 2NMTZ5e5rJlqsRjy1xc4fG59MBab1mvGBDmw5cg/Ab1WRCsRTNlfAy3GO0AAxkQxGItQ YTImVaencPinx+moKWoXqRuj7yUjRW7QJa9JAf6BBX5jyGVv3B/u+OuyjIDMvDXo0lkw i6hg== X-Received: by 10.220.76.137 with SMTP id c9mr3243079vck.48.1371746237643; Thu, 20 Jun 2013 09:37:17 -0700 (PDT) Received: from ?IPv6:2600:200f:1:30:a022:3277:7abe:2add? ([2600:200f:1:30:a022:3277:7abe:2add]) by mx.google.com with ESMTPSA id sr7sm1184871vdc.2.2013.06.20.09.37.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 09:37:16 -0700 (PDT) Message-ID: <51C32FB9.7050600@dyn.com> Date: Thu, 20 Jun 2013 12:37:13 -0400 From: Ofer Nave User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: provreg@ietf.org References: <51C328F3.7020301@dyn.com> <51C32EC0.7@knipp.de> In-Reply-To: <51C32EC0.7@knipp.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlsM/UeJ6b8F6C38AscTAEZm7yGRlO8NqndxfLyGLaXoMiU4Egiv6eqxT5WY7gEq61dxYeB Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:37:20 -0000 On 06/20/2013 12:33 PM, Klaus Malorny wrote: > On 20/06/13 18:08, Ofer Nave wrote: >> As an EPP noob, I'm confused by the same thing (being able to >> 'transfer' a >> contact object). >> >> I get the point of transferring a domain name because it represents >> ownership, >> like a title or deed. It can only be 'owned' by a single registrar >> at a time. >> But a contact is merely a data structure. Shouldn't contacts and >> hosts just be >> copied automatically by the gaining registrar in the case of a domain >> transfer? >> What does it mean to 'transfer' a contact, as opposed to merely >> copying the data? >> >> -ofer >> >> On 06/20/2013 12:04 PM, Seth Goldman wrote: >>> What do registrars typically do about contacts sponsored by a different >>> registrar after a domain transfer? This situation seems undesirable, >>> as it >>> prevents the gaining registrar from updating registrant contact >>> information in >>> the future. Do registrars just make a new contact as a matter of >>> course? Or do >>> they try to transfer over the existing contact? The former seems >>> more likely, >>> as the latter will not work if there are other domains with >>> references to that >>> contact object on the losing registrar. >>> > > Hi, > > I guess that nearly no registry has implemented the transfers of > contacts. The benefit is neglectible and introduces some unwanted side > effects. As Seth says, especially, automatically transferring contacts > along with the domain is a really bad idea, as these contacts may > still be linked with other domains of the losing registrar. > > Automatic copying of contacts could be done, but this increases the > garbage -- without copying, a registrar can theoretically reuse an > existing contact for the very same person he has created earlier. Host > objects cannot be copied, as the host's name is the (unique) key to > the EPP object (contrary to the ID of the contact, which is not part > of the content) and therefore no two hosts with the name may exist at > the same time. > > Another registry implementation approach is to use separate object/ID > spaces for each registrar. A registrar cannot see/access any object of > another registrar at all. In this case, copying is mandatory, or a new > set of contacts must be already provided when the domain transfer is > initiated (not possible in EPP without extensions). Thanks, that definitely helps clarify a few things that were previously fuzzy to me. -ofer From michael@mwyoung.ca Thu Jun 20 09:37:34 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF5221F9E3E for ; Thu, 20 Jun 2013 09:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJIeSB3Uvp7t for ; Thu, 20 Jun 2013 09:37:32 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 73A2D21F9E1C for ; Thu, 20 Jun 2013 09:37:32 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so16863879ief.40 for ; Thu, 20 Jun 2013 09:37:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=MpmyDUQC1IpiaMEzczHOM5/agBIVKc51a+u7PwCbKaE=; b=Q9ZIw6uPuH6eLY/K8UIMh+3fAbynnGGHEivAXmw1N66tB5goQBS6J0G1ZmdqfcUicS Tc/J2FxIhyM2M/fIRK6s148VUuSj5qAoONx8TFTLzWJnYWbmdclYFw0NnOlbhHfaS9Q2 sjIiaxgWT7zP83In2DtXp5mpA5XygVU269o2bBaWhnSmeRuIWseuWun9PIvRU0JV1X2s i6vsW4wWDMkChinJei1i8j7IhTVTbfHSB3jXARr1NXEhGG3pozgVPDqPjnHWdgitQu6X EKAByRO5v0uIKeD8+GfsBvuznuD3hoTOUG6UUHzciOMshmw26AzSxCMGZuGDk7+IV/UZ 5shg== X-Received: by 10.42.92.129 with SMTP id t1mr3673930icm.37.1371746251595; Thu, 20 Jun 2013 09:37:31 -0700 (PDT) Received: from [172.16.2.100] (dyn-wl-cs-66-79-255-215.nexicom.net. [66.79.255.215]) by mx.google.com with ESMTPSA id nm17sm11646885igb.5.2013.06.20.09.37.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 09:37:30 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_874F9B2E-0C54-4673-B00A-23B3C195D2B0" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: MICHAEL YOUNG In-Reply-To: <51C32AB8.8050508@centralnic.com> Date: Thu, 20 Jun 2013 12:37:27 -0400 Message-Id: <2604D527-C0F7-463D-A931-E8F2EF91018F@mwyoung.ca> References: <51C32AB8.8050508@centralnic.com> To: Gavin Brown X-Mailer: Apple Mail (2.1508) X-Gm-Message-State: ALoCoQlfRPNV/wd9OvO24yvRCveBAoMKTXAWmCslMWa7wM8HY5Z2jPmJZD4MtUV6WYhABtTqszHy Cc: EPP Provreg Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:37:34 -0000 --Apple-Mail=_874F9B2E-0C54-4673-B00A-23B3C195D2B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii These are much more common during bulk transfer operations, where one = registrar buys the assets of another. It is a needed function for that = use case. I've also seem some contact transfers around domain transfer operations = but as Gavin said, its not common practise. -Michael Young On 2013-06-20, at 12:15 PM, Gavin Brown = wrote: > We've operated an EPP server since 2005, and have only ever seen a > single contact transfer request - which was cancelled shortly after > being submitted. >=20 > Gavin. >=20 > On 20/06/2013 17:04, Seth Goldman wrote: >> What do registrars typically do about contacts sponsored by a = different >> registrar after a domain transfer? This situation seems undesirable, = as >> it prevents the gaining registrar from updating registrant contact >> information in the future. Do registrars just make a new contact as a >> matter of course? Or do they try to transfer over the existing = contact? >> The former seems more likely, as the latter will not work if there = are >> other domains with references to that contact object on the losing >> registrar. >>=20 >>=20 >> _______________________________________________ >> provreg mailing list >> provreg@ietf.org >> https://www.ietf.org/mailman/listinfo/provreg >>=20 >=20 > --=20 > Gavin Brown > Chief Technology Officer > CentralNic Ltd > Innovative, Reliable and Flexible Registry Services > for ccTLD, gTLD and private domain name registries > https://www.centralnic.com/ >=20 > CentralNic Ltd is a company registered in England and Wales with = company > number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg MICHAEL YOUNG michael@mwyoung.ca --Apple-Mail=_874F9B2E-0C54-4673-B00A-23B3C195D2B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii gavin.brown@centralnic.com&= gt; wrote:

We've operated an EPP server since 2005, and have only = ever seen a
single contact transfer request - which was cancelled = shortly after
being submitted.

Gavin.

On 20/06/2013 = 17:04, Seth Goldman wrote:
What do = registrars typically do about contacts sponsored by a = different
registrar after a domain transfer? This situation seems = undesirable, as
it prevents the gaining registrar from updating = registrant contact
information in the future. Do registrars just make = a new contact as a
matter of course? Or do they try to transfer over = the existing contact?
The former seems more likely, as the latter = will not work if there are
other domains with references to that = contact object on the = losing
registrar.


__________________________________________= _____
provreg mailing list
provreg@ietf.org
https://www.ietf.= org/mailman/listinfo/provreg


--
Gavin = Brown
Chief Technology Officer
CentralNic Ltd
Innovative, = Reliable and Flexible Registry Services
for ccTLD, gTLD and private = domain name registries
https://www.centralnic.com/
CentralNic Ltd is a company registered in England and Wales with = company
number 4985780. Registered Offices: 35-39 Moorgate, London, = EC2R 6AR.
_______________________________________________
provreg = mailing = list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg<= br>




MICHAEL = YOUNG




= --Apple-Mail=_874F9B2E-0C54-4673-B00A-23B3C195D2B0-- From mcanix@gmail.com Thu Jun 20 10:00:51 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E40921F9A37 for ; Thu, 20 Jun 2013 10:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiMUdtAabZ+q for ; Thu, 20 Jun 2013 10:00:50 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 67F6821F9590 for ; Thu, 20 Jun 2013 10:00:50 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b12so5800978wgh.7 for ; Thu, 20 Jun 2013 10:00:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:from:content-type:x-mailer:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version; bh=pUqH58BWduv91x0ssMoT3u7B8etLLeJNTWpWpaNByck=; b=nmiGVxIYrZ3kApoiGFPhLUqm4nhs6f2/DaXkehMupNvqsl7I/OL4qPjEf2H0eSLCHJ Eb42sWHimRrrjIbbkJ/tWa5dP5d0zNV8pUnSi7PfkKk5BcYaGP53imgDVf5Yf7lRdMn/ SUN82OLXmgXW26wFnU5HHg5gngxLGdG79TwK5yLQeCpRZV53hJ0FuqcxP2A526btClgy /QmEfu4myfyY+arpKqwzFTd73fXXRWxl4I927SB+DFpHQTDCtyhcFB4FkW9yAnMQVAgt oNhw8n3lRuLeXMywpNvAVa7I4ouk2EStKU4xgcEX7y/vyhk3AovRxZYjGXaKFy9WtNvz J2QA== X-Received: by 10.194.7.137 with SMTP id j9mr2627786wja.11.1371747649591; Thu, 20 Jun 2013 10:00:49 -0700 (PDT) Received: from [10.208.148.194] ([41.13.60.133]) by mx.google.com with ESMTPSA id ft10sm1755124wib.7.2013.06.20.10.00.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Jun 2013 10:00:48 -0700 (PDT) References: <51C328F3.7020301@dyn.com> <51C32EC0.7@knipp.de> From: mike Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (10B329) In-Reply-To: <51C32EC0.7@knipp.de> Message-Id: <6ABEE70D-0138-43E7-A256-2E1AD4BDCE62@gmail.com> Date: Thu, 20 Jun 2013 19:00:38 +0200 To: "provreg@ietf.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:00:51 -0000 All, > I guess that nearly no registry has implemented the transfers of contacts.= The benefit is neglectible and introduces some unwanted side effects. As Se= th says, especially, automatically transferring contacts along with the doma= in is a really bad idea, as these contacts may still be linked with other do= mains of the losing registrar. We've done the implementation for contact transfer but haven't found a use f= or it (yet) > Automatic copying of contacts could be done, but this increases the garbag= e -- without copying, a registrar can theoretically reuse an existing contac= t for the very same person he has created earlier. Contacts are duplicated on transfer and many rars replace these with their o= wn for contact ID uniformity (I would guess), so we're facing a contact garb= age collection sometime soon which should be fun... > Host objects cannot be copied, as the host's name is the (unique) key to t= he EPP object (contrary to the ID of the contact, which is not part of the c= ontent) and therefore no two hosts with the name may exist at the same time.= Funnily enough; host objects are the only object in our registry that are un= ique to the rar only, i.e two rars can have the same hostname. We copy host o= bjects (with some special control around subordinate and delegated hosts) on= transfer as well as contacts.=20 It might not be the neatest approach and requires some long term maintenance= but it works well enough! Regards, Michael O'Connell DNServices Registry Services= From ajs@anvilwalrusden.com Thu Jun 20 10:08:23 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD0821F9D47 for ; Thu, 20 Jun 2013 10:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlUAp219+nOa for ; Thu, 20 Jun 2013 10:08:17 -0700 (PDT) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 08F8F21F9D0C for ; Thu, 20 Jun 2013 10:08:16 -0700 (PDT) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id ECC3C8A031 for ; Thu, 20 Jun 2013 17:08:10 +0000 (UTC) Date: Thu, 20 Jun 2013 13:08:09 -0400 From: Andrew Sullivan To: provreg@ietf.org Message-ID: <20130620170809.GD41900@mx1.yitter.info> References: <51C32AB8.8050508@centralnic.com> <2604D527-C0F7-463D-A931-E8F2EF91018F@mwyoung.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2604D527-C0F7-463D-A931-E8F2EF91018F@mwyoung.ca> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:08:23 -0000 On Thu, Jun 20, 2013 at 12:37:27PM -0400, MICHAEL YOUNG wrote: > These are much more common during bulk transfer operations, where one registrar buys the assets of another. It is a needed function for that use case. But bulk transfer is usually not accomplished by retail EPP commands, so that might not be a good reason for the functionality to be there. My own view is that this is just a consequence of the data model implicit in EPP, and sponosors ("registrars") would be crazy not to set up contacts they control themselves and then replace the old contact data with new after a domain transfer. (Same thing of external hosts.) Best, A -- Andrew Sullivan ajs@anvilwalrusden.com From jan@irial.com Thu Jun 20 15:14:39 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC4411E80E4 for ; Thu, 20 Jun 2013 15:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIoW0Dcwjhdd for ; Thu, 20 Jun 2013 15:14:35 -0700 (PDT) Received: from ns1.knots.net (mail.oa5.net [89.187.75.200]) by ietfa.amsl.com (Postfix) with ESMTP id F136921F9EF6 for ; Thu, 20 Jun 2013 15:14:33 -0700 (PDT) Received: from [192.168.192.181] (ns1.knots.net [89.187.75.200]) jan (authenticated bits=0) by ns1.knots.net (8.14.2/8.12.11) with ESMTP id r5KMEVwt002043 sender jan@irial.com for ; Thu, 20 Jun 2013 23:14:32 +0100 Received: from [192.168.192.181] ([81.233.246.204] helo=[192.168.192.181]) by mail.oa5.com; 20 Jun 2013 22:14:31 +0000 Message-ID: <51C37EC7.8090700@irial.com> Date: Fri, 21 Jun 2013 00:14:31 +0200 From: Jan Saell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: provreg@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Assp-Whitelisted: Yes X-Assp-Envelope-From: jan@irial.com X-Assp-Intended-For: provreg@ietf.org Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 22:14:39 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there! As a regsistarar at .SE i can tell you how the .SE EPP server works. Host objects are owned by the sponsoring client of the domain itself, and when you do transfers the hosts in a domain gets transferred automatically. When doing a domain transfer, the contact object of the domain is copied and set as the registrant of the domain. This solves the problems with other domain belonging to the old contact at the old registrar. The new registrar gets a notification that the epp server has created a new contact for that registrar, so to be able to updates its own database. This usually leads to me as a registrar changing the domain registrant to a new or existing contact object that I have. And hopefully deleting the old one. Not all registrars are deleting old ones so this leads to some "junk" in the database, but there are a discussion about automatically deleting old, unused ones. Best regards jan On 06/20/2013 06:04 PM, Seth Goldman wrote: > What do registrars typically do about contacts sponsored by a different > registrar after a domain transfer? This situation seems undesirable, as > it prevents the gaining registrar from updating registrant contact > information in the future. Do registrars just make a new contact as a > matter of course? Or do they try to transfer over the existing contact? > The former seems more likely, as the latter will not work if there are > other domains with references to that contact object on the losing > registrar. > > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > - -- +------------------------------------------------------------------- ! Irial / YASK AB ! Att: Jan Saell ! Box 59, S-692 21 KUMLA, SWEDEN ! Tel: 019-58 25 15 Int +46-19 58 25 15 Fax +46-19 58 38 05 ! E-mail: jan@irial.com ! PGP Fingerprint: E957 23C8 9F51 0958 B9AD 7F18 404A 5DA1 F944 A08B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHDfscACgkQQEpdoflEoIsFhgCcDcv2x0btS9H9oj7xdr0ULe7w UaAAn1/OccK9bC2JMuAqUDz7cNkgIV/c =AnpZ -----END PGP SIGNATURE----- From ewout@mdmail.nl Fri Jun 21 00:35:11 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A2F21E80B2 for ; Fri, 21 Jun 2013 00:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f9O+1hGqI9Wu for ; Fri, 21 Jun 2013 00:35:07 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id AF75721F9B4B for ; Fri, 21 Jun 2013 00:35:06 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id ey16so368921wid.5 for ; Fri, 21 Jun 2013 00:35:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=hd6G7A2XdGQ/I7fK8aBIsNcYp3ZHFmLgn5q/h45nTL8=; b=FE4a8D4uPM+jYkhlHrwMss/ED6w7MW4b6yc/ZXtSWZ2d85xN/UD8PHlQdVcAHEozO0 3tR6xEx25mZw+i4j2B3iPb3VeFU86Tze+XUULquFZpb6wnDlV3G6xhE9uAYD5Dt20MVC 2sP1W1JSuVxjDv2kPbpZAAhIDsrruolBIRlZqpaHmp2yfPx+jsKyFtPDmjayC9ylJgdj eDh/zOiU8/hzUsDXvByJ92pvwrJWTmCGX6gHbEcTSgyHlS3IOMAzxRyF8u0ibZmH41Uc g+fQn8MbPaAY3UTxHTWhX1ntvlSjpB8nDJc82TkB5xwSnpcb5BZ1ytshB+KfeVK3kfnN oV9g== MIME-Version: 1.0 X-Received: by 10.180.106.163 with SMTP id gv3mr1830148wib.53.1371800105485; Fri, 21 Jun 2013 00:35:05 -0700 (PDT) Sender: ewout@mdmail.nl Received: by 10.216.189.132 with HTTP; Fri, 21 Jun 2013 00:35:05 -0700 (PDT) X-Originating-IP: [62.100.60.245] In-Reply-To: <51C37EC7.8090700@irial.com> References: <51C37EC7.8090700@irial.com> Date: Fri, 21 Jun 2013 09:35:05 +0200 X-Google-Sender-Auth: Y_GjPPf5WC2l2fqsXEoIfhC_5WY Message-ID: From: Ewout de Graaf To: "provreg@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f3ba525fd97c004dfa519ff X-Gm-Message-State: ALoCoQkyheMIwXegoRKj2PGHN1tXeFGRbkAprPQuD9lmS4uDJLUhto8BRO91kRaMKKFFit9Hi9ga Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 07:36:48 -0000 --e89a8f3ba525fd97c004dfa519ff Content-Type: text/plain; charset=ISO-8859-1 Registrars SHOULD change contacts upon an incoming transfer, because the same registrant might have more then one domain name from the same registry with this registrar. So upon incoming transfer of a domain name, a registrars software should first check if this client owns other domain names, and re-use contact information from those domain names on the incoming transfer. Most registries create copies of contacts when a domain is transferred, so if the client does not own other domain names, you might use these contacts and insert the contact handles into your own database. Or you can create new contacts, whatever you want. Please clean up the mess afterwards... Kind regards, Ewout de Graaf mijndomein.nl 2013/6/21 Jan Saell > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi there! > > As a regsistarar at .SE i can tell you how the .SE EPP server works. > > Host objects are owned by the sponsoring client of the domain itself, > and when you do transfers the hosts in a domain gets transferred > automatically. > > When doing a domain transfer, the contact object of the domain is copied > and set as the registrant of the domain. > > This solves the problems with other domain belonging to the old contact > at the old registrar. > > The new registrar gets a notification that the epp server has created a > new contact for that registrar, so to be able to updates its own database. > > This usually leads to me as a registrar changing the domain registrant > to a new or existing contact object that I have. And hopefully deleting > the old one. > > Not all registrars are deleting old ones so this leads to some "junk" in > the database, but there are a discussion about automatically deleting > old, unused ones. > > Best regards > jan > > On 06/20/2013 06:04 PM, Seth Goldman wrote: > > What do registrars typically do about contacts sponsored by a different > > registrar after a domain transfer? This situation seems undesirable, as > > it prevents the gaining registrar from updating registrant contact > > information in the future. Do registrars just make a new contact as a > > matter of course? Or do they try to transfer over the existing contact? > > The former seems more likely, as the latter will not work if there are > > other domains with references to that contact object on the losing > > registrar. > > > > > > _______________________________________________ > > provreg mailing list > > provreg@ietf.org > > https://www.ietf.org/mailman/listinfo/provreg > > > > - -- > +------------------------------------------------------------------- > ! Irial / YASK AB > ! Att: Jan Saell > ! Box 59, S-692 21 KUMLA, SWEDEN > ! Tel: 019-58 25 15 Int +46-19 58 25 15 Fax +46-19 58 38 05 > ! E-mail: jan@irial.com > ! PGP Fingerprint: E957 23C8 9F51 0958 B9AD 7F18 404A 5DA1 F944 A08B > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlHDfscACgkQQEpdoflEoIsFhgCcDcv2x0btS9H9oj7xdr0ULe7w > UaAAn1/OccK9bC2JMuAqUDz7cNkgIV/c > =AnpZ > -----END PGP SIGNATURE----- > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > --e89a8f3ba525fd97c004dfa519ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Registrars SHOULD change contacts upon an incoming transfer, be= cause the same registrant might have more then one domain name from the sam= e registry with this registrar.

<= /div>
= So upon incoming transfer of a domain name, a registrars software should fi= rst check if this client owns other domain names, and re-use contact inform= ation from those domain names on the incoming transfer.

<= /div>
= Most registries create copies of contacts when a domain is transferred, so = if the client does not own other domain names, you might use these contacts= and insert the contact handles into your own database. Or you can create n= ew contacts, whatever you want. Please clean up the mess afterwards...


= Kind regards,

Ewout de Graaf


2013/6/21 Jan Saell &l= t;jan@irial.com><= /span>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi there!

As a regsistarar at .SE i can tell you how the .SE EPP server works.

Host objects are owned by the sponsoring client of the domain itself,
and when you do transfers the hosts in a domain gets transferred
automatically.

When doing a domain transfer, the contact object of the domain is copied and set as the registrant of the domain.

This solves the problems with other domain belonging to the old contact
at the old registrar.

The new registrar gets a notification that the epp server has created a
new contact for that registrar, so to be able to updates its own database.<= br>
This usually leads to me as a registrar changing the domain registrant
to a new or existing contact object that I have. And hopefully deleting
the old one.

Not all registrars are deleting old ones so this leads to some "junk&q= uot; in
the database, but there are a discussion about automatically deleting
old, unused ones.

Best regards
jan

On 06/20/2013 06:04 PM, Seth Goldman wrote:
> What do registrars typically do about contacts sponsored by a differen= t
> registrar after a domain transfer? This situation seems undesirable, a= s
> it prevents the gaining registrar from updating registrant contact
> information in the future. Do registrars just make a new contact as a<= br> > matter of course? Or do they try to transfer over the existing contact= ?
> The former seems more likely, as the latter will not work if there are=
> other domains with references to that contact object on the losing
> registrar.
>
>
> ________________________________________= _______
> provreg mailing list
> provreg@ietf.org
> https://www.ietf.org/mailman/listinfo/provreg
>

- --
+-------------------------------------------------------------------
! Irial / YASK AB
! Att: Jan Saell
! Box 59, S-692 21 KUMLA, SWEDEN
! Tel: 019-58 25 15 =A0 =A0 Int +46-19 58 25 15 =A0 =A0 Fax +46-19 58 38 05=
! E-mail: jan@irial.com
! PGP Fingerprint: E957 23C8 9F51 0958 B9AD =A07F18 404A 5DA1 F944 A08B

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHDfscACgkQQEpdoflEoIsFhgCcDcv2x0btS9H9oj7xdr0ULe7w
UaAAn1/OccK9bC2JMuAqUDz7cNkgIV/c
=3DAnpZ
-----END PGP SIGNATURE-----
___________________________________= ____________
provreg mailing list
provreg@ietf.org
https://www.ietf.org/mailman/listinfo/provreg

--e89a8f3ba525fd97c004dfa519ff-- From keith@blacknight.com Fri Jun 21 03:40:26 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6495811E8182 for ; Fri, 21 Jun 2013 03:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9h6zYn4VG0bu for ; Fri, 21 Jun 2013 03:40:21 -0700 (PDT) Received: from nineve.blacknight.ie (nineve.blacknight.ie [81.17.243.129]) by ietfa.amsl.com (Postfix) with ESMTP id BDEA021E80DB for ; Fri, 21 Jun 2013 03:40:21 -0700 (PDT) Received: by nineve.blacknight.ie (Postfix, from userid 1010) id 1E4DD58090; Fri, 21 Jun 2013 11:40:13 +0100 (IST) Date: Fri, 21 Jun 2013 11:40:13 +0100 From: Keith Gaughan To: Ofer Nave Message-ID: <20130621104012.GZ31423@nineve.blacknight.ie> References: <20130620160658.6412E5A4036@merlin.blacknight.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130620160658.6412E5A4036@merlin.blacknight.ie> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: provreg@ietf.org Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 10:40:26 -0000 On Thu, Jun 20, 2013 at 12:08:19PM -0400, Ofer Nave wrote: > As an EPP noob, I'm confused by the same thing (being able to 'transfer' a > contact object). That's a matter of parsimony in the protocol: each object shares a uniform interface, which helps establish a uniform set of abstractions. That said, while the operation might be *possible*, but that doesn't mean that registries necessarily have to support it. > I get the point of transferring a domain name because it represents > ownership, like a title or deed. No. It's a transfer of *sponsorship*. Registrars *sponsor* objects, they don't own them as such. > It can only be 'owned' by a single registrar at a time. But a contact > is merely a data structure. Shouldn't contacts and hosts just be > copied automatically by the gaining registrar in the case of a domain > transfer? It's a matter of changing who has responsibility for the object in question. But, as I said, not every object necessarily has to implement every EPP operation. Typically, registries don't allow the explicit transfer of host objects and contacts, though it's technically possible in the protocol. Contacts may also be tied to multiple domains or none, so it doesn't make sense that, if a domain is transferred, all its associated contacts are also transferred. > What does it mean to 'transfer' a contact, as opposed to merely > copying the data? If the registry supports contact transfers, it's a transfer of responsibility for the object. K. -- Keith Gaughan, Development Lead PGP/GPG key ID: 82AC3634 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From keith@blacknight.com Fri Jun 21 04:36:40 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D13321F9982 for ; Fri, 21 Jun 2013 04:36:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqxhJ6ZW9rej for ; Fri, 21 Jun 2013 04:36:35 -0700 (PDT) Received: from nineve.blacknight.ie (nineve.blacknight.ie [81.17.243.129]) by ietfa.amsl.com (Postfix) with ESMTP id 9740321F9977 for ; Fri, 21 Jun 2013 04:36:35 -0700 (PDT) Received: by nineve.blacknight.ie (Postfix, from userid 1010) id 9B4E558090; Fri, 21 Jun 2013 12:36:32 +0100 (IST) Date: Fri, 21 Jun 2013 12:36:32 +0100 From: Keith Gaughan To: EPP Provreg Message-ID: <20130621113632.GA31423@nineve.blacknight.ie> References: <20130620160315.9A9145A4036@merlin.blacknight.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130620160315.9A9145A4036@merlin.blacknight.ie> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 11:36:40 -0000 On Thu, Jun 20, 2013 at 12:04:40PM -0400, Seth Goldman wrote: > What do registrars typically do about contacts sponsored by a > different registrar after a domain transfer? This situation seems > undesirable, as it prevents the gaining registrar from updating > registrant contact information in the future. Do registrars just make > a new contact as a matter of course? Or do they try to transfer over > the existing contact? The former seems more likely, as the latter will > not work if there are other domains with references to that contact > object on the losing registrar. I've integrated our domain management system with a good number of registries at this point. I've noticed a number of different models for handling contacts as part of domain transfers. The first model is that contacts associated with the domain are automatically duplicated upon the transfer of a domain. Second is that the associated contacts are not duplicated, but the fact that the contacts are associated with a domain under the registrar's control transitively gives the registrar read-only access to the existing contacts. Naturally, this only works as long as the contacts are associated, and can't be used as a way for registrars to get access to the contact data of other registrars in general. This is much like the temporary read-only typically granted to contacts before transfer when a registrar has the ROID and authcode associated with a domain they intend to transfer. Finally, I've came across registries that give no access to contacts not sponsored by the registrar in question and which do not duplicate contacts. Generally, I've been able to convince them to implement one of the first two models. We typically duplicate the existing contact unless we know beforehand that the registry automatically duplicates the contact for us. As others have said, contact transfers aren't typically implemented or even useful. K. -- Keith Gaughan, Development Lead PGP/GPG key ID: 82AC3634 Blacknight Internet Solutions Ltd. 12A Barrowside Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 From jkolker@godaddy.com Fri Jun 21 06:17:43 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89DA21E8115 for ; Fri, 21 Jun 2013 06:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRWUtWYFTwJG for ; Fri, 21 Jun 2013 06:17:37 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id BC6B021E8116 for ; Fri, 21 Jun 2013 06:17:36 -0700 (PDT) Received: from BLUPR02MB034.namprd02.prod.outlook.com (10.242.191.17) by BLUPR02MB035.namprd02.prod.outlook.com (10.242.191.21) with Microsoft SMTP Server (TLS) id 15.0.702.21; Fri, 21 Jun 2013 13:17:32 +0000 Received: from BLUPR02MB034.namprd02.prod.outlook.com ([169.254.3.252]) by BLUPR02MB034.namprd02.prod.outlook.com ([169.254.3.70]) with mapi id 15.00.0702.005; Fri, 21 Jun 2013 13:17:32 +0000 From: Jody Kolker To: EPP Provreg Thread-Topic: [provreg] Contacts after a Domain Transfer Thread-Index: AQHObnOThZdH/eWnUU620uwBnO7eh5lAJZvQ Date: Fri, 21 Jun 2013 13:17:31 +0000 Message-ID: References: <20130620160315.9A9145A4036@merlin.blacknight.ie> <20130621113632.GA31423@nineve.blacknight.ie> In-Reply-To: <20130621113632.GA31423@nineve.blacknight.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.202.161.57] x-forefront-antispam-report: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BLUPR02MB035; H:BLUPR02MB034.namprd02.prod.outlook.com; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: godaddy.com Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 13:17:43 -0000 At GoDaddy, we have always created new contacts with the current contact in= formation after the transfer so that the customer can manage the contact at= Go Daddy.=20 Thanks, Jody Kolker GoDaddy -----Original Message----- From: provreg-bounces@ietf.org [mailto:provreg-bounces@ietf.org] On Behalf = Of Keith Gaughan Sent: Friday, June 21, 2013 6:37 AM To: EPP Provreg Subject: Re: [provreg] Contacts after a Domain Transfer On Thu, Jun 20, 2013 at 12:04:40PM -0400, Seth Goldman wrote: > What do registrars typically do about contacts sponsored by a=20 > different registrar after a domain transfer? This situation seems=20 > undesirable, as it prevents the gaining registrar from updating=20 > registrant contact information in the future. Do registrars just make=20 > a new contact as a matter of course? Or do they try to transfer over=20 > the existing contact? The former seems more likely, as the latter will=20 > not work if there are other domains with references to that contact=20 > object on the losing registrar. I've integrated our domain management system with a good number of registri= es at this point. I've noticed a number of different models for handling co= ntacts as part of domain transfers. The first model is that contacts associated with the domain are automatical= ly duplicated upon the transfer of a domain. Second is that the associated contacts are not duplicated, but the fact tha= t the contacts are associated with a domain under the registrar's control t= ransitively gives the registrar read-only access to the existing contacts. = Naturally, this only works as long as the contacts are associated, and can= 't be used as a way for registrars to get access to the contact data of oth= er registrars in general. This is much like the temporary read-only typical= ly granted to contacts before transfer when a registrar has the ROID and au= thcode associated with a domain they intend to transfer. Finally, I've came across registries that give no access to contacts not sp= onsored by the registrar in question and which do not duplicate contacts. = Generally, I've been able to convince them to implement one of the first tw= o models. We typically duplicate the existing contact unless we know beforehand that = the registry automatically duplicates the contact for us. As others have sa= id, contact transfers aren't typically implemented or even useful. K. -- Keith Gaughan, Development Lead PGP/GPG key ID: 82AC3634 Blacknight Internet Solutions Ltd. 12A Barrowside = Business Park, Carlow, Ireland Registered in Ireland, Company No.: 370845 _= ______________________________________________ provreg mailing list provreg@ietf.org https://www.ietf.org/mailman/listinfo/provreg From lem@isc.org Fri Jun 21 08:09:38 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E245D21F9FA0 for ; Fri, 21 Jun 2013 08:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkVK5axtzMk7 for ; Fri, 21 Jun 2013 08:09:38 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 589B221F9D9D for ; Fri, 21 Jun 2013 08:09:38 -0700 (PDT) Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id 7A16BC94FC for ; Fri, 21 Jun 2013 15:09:31 +0000 (UTC) (envelope-from lem@isc.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1371827377; bh=M2sdHq4C5+0CsFsv+mditrDnay5lP+Wq4twNWMb3X7Y=; h=Subject:From:In-Reply-To:Date:References:To; b=swrmwnSI8+w3Mxrdr7UIo+OkRsUlZFamObBUu3yVREve8Gz7Uq9KOG6cttvA72c4f OMya7kJq8DESwFCI9o7bTs/CohZRxjMZhUuOumbVrNZD9pCnO0LxF/cf2TyVyaX4Fk NmgWa3H26PauwDuCicFOadLBdJE3LFVesvvkD/PQ= Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mail.isc.org", Issuer "RapidSSL CA" (not verified)) by mx.pao1.isc.org (Postfix) with ESMTPS for ; Fri, 21 Jun 2013 15:09:31 +0000 (UTC) (envelope-from lem@isc.org) Received: from lembook.lem (z65-50-116-115.ips.direcpath.com [65.50.116.115]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 41C32216C40 for ; Fri, 21 Jun 2013 15:09:31 +0000 (UTC) (envelope-from lem@isc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1283) From: =?iso-8859-1?Q?Luis_Mu=F1oz?= In-Reply-To: Date: Fri, 21 Jun 2013 11:09:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3398A399-C0A4-4C83-8971-6B95DA36CB69@isc.org> References: <51C37EC7.8090700@irial.com> To: provreg@ietf.org X-Mailer: Apple Mail (2.1283) X-DCC--Metrics: post.isc.org; whitelist Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:09:39 -0000 On Jun 21, 2013, at 3:35 AM, Ewout de Graaf wrote: > Or you can create > new contacts, whatever you want. Please clean up the mess = afterwards... Is there any preferred way of doing this? How about sending a poll message prior to purging "orphaned" objects = after a reasonable time? What would that "reasonable" time be? Best regards -lem =20= From gavin.brown@centralnic.com Fri Jun 21 08:37:05 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DA8F21F9926 for ; Fri, 21 Jun 2013 08:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.345 X-Spam-Level: X-Spam-Status: No, score=-0.345 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ly3FYWC3R+PB for ; Fri, 21 Jun 2013 08:37:01 -0700 (PDT) Received: from smtp.centralnic.com (unknown [193.105.170.214]) by ietfa.amsl.com (Postfix) with ESMTP id D997921F9458 for ; Fri, 21 Jun 2013 08:37:00 -0700 (PDT) Received: from Gavins-iMac.local (82-68-174-118.in-addr.centralnic.net [82.68.174.118]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by smtp.centralnic.com (Postfix) with ESMTPSA id 71D017203E8; Fri, 21 Jun 2013 15:36:57 +0000 (UTC) Message-ID: <51C47318.9050808@centralnic.com> Date: Fri, 21 Jun 2013 16:36:56 +0100 From: Gavin Brown Organization: CentralNic Ltd User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: =?UTF-8?B?THVpcyBNdcOxb3o=?= References: <51C37EC7.8090700@irial.com> <3398A399-C0A4-4C83-8971-6B95DA36CB69@isc.org> In-Reply-To: <3398A399-C0A4-4C83-8971-6B95DA36CB69@isc.org> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: provreg@ietf.org Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:37:05 -0000 On 21/06/2013 16:09, Luis Muñoz wrote: > > On Jun 21, 2013, at 3:35 AM, Ewout de Graaf wrote: > >> Or you can create >> new contacts, whatever you want. Please clean up the mess afterwards... > > Is there any preferred way of doing this? > > How about sending a poll message prior to purging "orphaned" objects after a reasonable time? What would that "reasonable" time be? Various server-side approaches were discussed on the regops list back in 2011: http://nlnetlabs.nl/mailman/private/regops/2011-October/thread.html G. -- Gavin Brown Chief Technology Officer CentralNic Ltd Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ CentralNic Ltd is a company registered in England and Wales with company number 4985780. Registered Offices: 35-39 Moorgate, London, EC2R 6AR. From paf@frobbit.se Sat Jun 22 00:15:18 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE2A21F9DCF for ; Sat, 22 Jun 2013 00:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUJeytdF2r3e for ; Sat, 22 Jun 2013 00:15:18 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) by ietfa.amsl.com (Postfix) with ESMTP id D145021F9DCC for ; Sat, 22 Jun 2013 00:15:17 -0700 (PDT) Received: from vpn-client-208.netnod.se (vpn-client-208.netnod.se [192.71.80.208]) by mail.frobbit.se (Postfix) with ESMTPSA id 8682A215C7; Sat, 22 Jun 2013 09:15:16 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= In-Reply-To: <3398A399-C0A4-4C83-8971-6B95DA36CB69@isc.org> Date: Sat, 22 Jun 2013 09:15:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51C37EC7.8090700@irial.com> <3398A399-C0A4-4C83-8971-6B95DA36CB69@isc.org> To: =?iso-8859-1?Q?Luis_Mu=F1oz?= X-Mailer: Apple Mail (2.1508) Cc: provreg@ietf.org Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 07:15:19 -0000 On 21 jun 2013, at 17:09, Luis Mu=F1oz wrote: > On Jun 21, 2013, at 3:35 AM, Ewout de Graaf wrote: >=20 >> Or you can create >> new contacts, whatever you want. Please clean up the mess = afterwards... >=20 > Is there any preferred way of doing this? >=20 > How about sending a poll message prior to purging "orphaned" objects = after a reasonable time? What would that "reasonable" time be? I think the registry have to be very careful about making changes in the = registry database as that is a mirror of what the registrar do have in = its database. Just because a contact object in the registry database is = orphaned from the registry point of view, maybe it is not in the = registrar database. It might be used at a different registry. And as = long as the individual the object is describing is a customer of the = registrar, the registrar might when a new domain name is registered try = to reuse the same object. That said, the only reasonable way for a registry to remove objects I = think are: - Ensure the object has really been orphaned for quite some time (so = that it does not create a race condition between creation of the object = and registration of a domain name). This must be much longer than the = longest time interval existing in the state machine in the registry. - When the object is removed, inform via notification visible via poll. - When a removed object is used, a special error code is used to inform = on the matter so that the registrar know that in that specific case the = fallback is to go back, create the object again, and then redo whatever = operation failed. Patrik From jan@irial.com Sat Jun 22 01:12:36 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2118221F9C6F for ; Sat, 22 Jun 2013 01:12:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ektYkhv8OzWX for ; Sat, 22 Jun 2013 01:12:30 -0700 (PDT) Received: from ns1.knots.net (mail.oa5.net [89.187.75.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8138A21F9C6C for ; Sat, 22 Jun 2013 01:12:29 -0700 (PDT) Received: from [192.168.192.181] (ns1.knots.net [89.187.75.200]) jan (authenticated bits=0) by ns1.knots.net (8.14.2/8.12.11) with ESMTP id r5M8CQVG026025 sender jan@irial.com for ; Sat, 22 Jun 2013 09:12:27 +0100 Received: from [192.168.192.181] ([81.233.246.204] helo=[192.168.192.181]) by mail.oa5.com; 22 Jun 2013 08:12:26 +0000 Message-ID: <51C55C6A.4010701@irial.com> Date: Sat, 22 Jun 2013 10:12:26 +0200 From: Jan Saell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: provreg@ietf.org References: <51C37EC7.8090700@irial.com> <3398A399-C0A4-4C83-8971-6B95DA36CB69@isc.org> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Assp-Whitelisted: Yes X-Assp-Envelope-From: jan@irial.com X-Assp-Intended-For: provreg@ietf.org Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 08:12:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think that this is more or less exactly what .se is going to do except the last point. And also as a epp client programmer I can confirm that an object don’t exists error code is sufficient. We dont need an extra error code for this in my opinion. My code knows that if you get an object dont exists error code when trying to register a new domain, that it has do "re-create" the owner again. On 06/22/2013 09:15 AM, Patrik Fältström wrote: > > On 21 jun 2013, at 17:09, Luis Muñoz wrote: > >> On Jun 21, 2013, at 3:35 AM, Ewout de Graaf wrote: >> >>> Or you can create >>> new contacts, whatever you want. Please clean up the mess afterwards... >> >> Is there any preferred way of doing this? >> >> How about sending a poll message prior to purging "orphaned" objects after a reasonable time? What would that "reasonable" time be? > > I think the registry have to be very careful about making changes in the registry database as that is a mirror of what the registrar do have in its database. Just because a contact object in the registry database is orphaned from the registry point of view, maybe it is not in the registrar database. It might be used at a different registry. And as long as the individual the object is describing is a customer of the registrar, the registrar might when a new domain name is registered try to reuse the same object. > > That said, the only reasonable way for a registry to remove objects I think are: > > - Ensure the object has really been orphaned for quite some time (so that it does not create a race condition between creation of the object and registration of a domain name). This must be much longer than the longest time interval existing in the state machine in the registry. > > - When the object is removed, inform via notification visible via poll. > > - When a removed object is used, a special error code is used to inform on the matter so that the registrar know that in that specific case the fallback is to go back, create the object again, and then redo whatever operation failed. > > Patrik > > _______________________________________________ > provreg mailing list > provreg@ietf.org > https://www.ietf.org/mailman/listinfo/provreg > - -- +------------------------------------------------------------------- ! Irial / YASK AB ! Att: Jan Saell ! Box 59, S-692 21 KUMLA, SWEDEN ! Tel: 019-58 25 15 Int +46-19 58 25 15 Fax +46-19 58 38 05 ! E-mail: jan@irial.com ! PGP Fingerprint: E957 23C8 9F51 0958 B9AD 7F18 404A 5DA1 F944 A08B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlHFXGoACgkQQEpdoflEoIvGFgCffDdxJsfdjqVli0QP2Dn+AzMb xdoAoLWBit59xMw0HJHBd2F1lwryPcXF =GC53 -----END PGP SIGNATURE----- From ewout@mdmail.nl Sat Jun 22 01:36:45 2013 Return-Path: X-Original-To: provreg@ietfa.amsl.com Delivered-To: provreg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA23121F9A7E for ; Sat, 22 Jun 2013 01:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXhTozi8Gbx2 for ; Sat, 22 Jun 2013 01:36:41 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 3EAA721F9A24 for ; Sat, 22 Jun 2013 01:36:40 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w56so7092108wes.11 for ; Sat, 22 Jun 2013 01:36:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:x-originating-ip:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :x-gm-message-state; bh=wr6crELWRCtDxqrAFTDf1R4AA9Xbj4LSo41+d7oo7Aw=; b=iwLJxAzkeaJ0DiBobd7BcgeIwv5paA9pxL0+od55CnmMIHiCFHjQr4PH/78H2bfhzE jEI8JOr1RQPhhn0f34U+I6nbvoQSq/hwPFnSdj7r9/ugGD00/q7eAvS5A7ck7T8chCv+ jBMYghiVZk9bWaEqkIHjIiixeMZVga8Flb8celAEO1+7j+CsjbXafazeIDlioCiROfpw VnV4VGS0jQyIqWHUUL6e70gCBoX5AQ3TtZDIGTYnKCoOJSSTabB+qpZwMAnAz9gThDon gR8dxEj3QO06tDkclXgrdrbz/e8cBw7D4l1h0dIMCbfcQRkp9fh9jabSo2JChIFXBPMa QzSQ== MIME-Version: 1.0 X-Received: by 10.180.106.163 with SMTP id gv3mr1084818wib.53.1371890200268; Sat, 22 Jun 2013 01:36:40 -0700 (PDT) Sender: ewout@mdmail.nl Received: by 10.216.189.132 with HTTP; Sat, 22 Jun 2013 01:36:40 -0700 (PDT) X-Originating-IP: [84.245.47.200] In-Reply-To: References: <51C37EC7.8090700@irial.com> <3398A399-C0A4-4C83-8971-6B95DA36CB69@isc.org> Date: Sat, 22 Jun 2013 10:36:40 +0200 X-Google-Sender-Auth: puJBsZMW5tJchfl_axkGHG6KmSs Message-ID: From: Ewout de Graaf To: "provreg@ietf.org" Content-Type: multipart/alternative; boundary=e89a8f3ba5250ed5ca04dfba141b X-Gm-Message-State: ALoCoQk3Xjnmy8kti59nn0j1hzYXxHBSZff874Ov+PPZYCzz1JM0Xdc2SdR32e+loB4JEpeSNFGR Subject: Re: [provreg] Contacts after a Domain Transfer X-BeenThere: provreg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: EPP discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 08:36:46 -0000 --e89a8f3ba5250ed5ca04dfba141b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2013/6/22 Patrik F=E4ltstr=F6m > I think the registry have to be very careful about making changes in the > registry database as that is a mirror of what the registrar do have in it= s > database. Just because a contact object in the registry database is > orphaned from the registry point of view, maybe it is not in the registra= r > database. It might be used at a different registry. And as long as the > individual the object is describing is a customer of the registrar, the > registrar might when a new domain name is registered try to reuse the sam= e > object. I think a registry should *never* discard contact or other objects that are sponsored by a registrar. We as registrars keep our records, and if the registry deletes stuff, we need to know it is deleted to update our records. So if contacts are orphaned, registries should provide the registrars with good lists of orphaned contacts and stimulate them to clean up their own mess... Regards, Ewout de Graaf mijndomein.nl --e89a8f3ba5250ed5ca04dfba141b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= 2013/6/22 Patrik F=E4ltstr=F6m <paf@frobbit.se>
I think the registry have to be very careful about making changes in the re= gistry database as that is a mirror of what the registrar do have in its da= tabase. Just because a contact object in the registry database is orphaned = from the registry point of view, maybe it is not in the registrar database.= It might be used at a different registry. And as long as the individual th= e object is describing is a customer of the registrar, the registrar might = when a new domain name is registered try to reuse the same object.

I think a registry should *never* discard contact or other objects tha= t are sponsored by a registrar.

We as registrars keep our records, and if the registry deletes stuff, = we need to know it is deleted to update our records.

So if contacts are orphaned, registries should provide the registrars = with good lists of orphaned contacts and stimulate them to clean up their o= wn mess...



Regards,

=
Ewout de Graaf
--e89a8f3ba5250ed5ca04dfba141b--