From owner-ietf-provreg@cafax.se Tue Nov 4 07:48:07 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12522 for ; Tue, 4 Nov 2003 07:48:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH0bZ-0004oF-00 for provreg-archive@ietf.org; Tue, 04 Nov 2003 07:48:17 -0500 Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx with esmtp (Exim 4.12) id 1AH0bZ-0004oB-00 for provreg-archive@ietf.org; Tue, 04 Nov 2003 07:48:17 -0500 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA4CUldF017830 for ; Tue, 4 Nov 2003 13:30:47 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hA4CUl9H017829 for ietf-provreg-outgoing; Tue, 4 Nov 2003 13:30:47 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA4CUkdF017824 for ; Tue, 4 Nov 2003 13:30:46 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hA4CUjha013752; Tue, 4 Nov 2003 07:30:45 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2657.72) id ; Tue, 4 Nov 2003 07:30:44 -0500 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF01A70772@vsvapostal8.vasrv.verisign.com> From: "Hollenbeck, Scott" To: "'Antony Perkov'" , "'ietf-provreg@cafax.se'" Subject: [ietf-provreg] RE: Grace periods Date: Tue, 4 Nov 2003 07:30:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk Antony, No, I have no intention of updating the RGP document to include descriptions of status values that have nothing to do with the RGP. There may, however, be some value in defining a new extension that describes some of the policy-based grace periods that you described below. But -- there's already a status value to describe what I think you mean when you say "Transfer grace period". See the description of the "pendingTransfer" status in the domain draft. For that matter, it may make sense to use the other "pending" status values to describe the add and renew grace periods, as in "this action has been requested but hasn't yet been fully completed". Would that make sense? -Scott- > -----Original Message----- > From: Antony Perkov [mailto:antony.perkov@poptel.coop] > Sent: Tuesday, November 04, 2003 6:04 AM > To: ietf-provreg@cafax.se > Cc: shollenbeck@verisign.com > Subject: Grace periods > > > Are there any plans to update the > draft-hollenbeck-epp-rgp-01.txt document > to include status values for grace periods other than "redemption"? > > I'm interested in status values for the other grace periods > described at > http://www.dnso.org/dnso/notes/20030323.DeletesTF-final-report .html which are: * Add grace period * Auto renew grace period * Renew grace period * Transfer grace period It seems to me that it would be useful to be able to provide registrars this information via the command. From owner-ietf-provreg@cafax.se Wed Nov 5 08:49:30 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05536 for ; Wed, 5 Nov 2003 08:49:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHO2X-0004Pt-00 for provreg-archive@ietf.org; Wed, 05 Nov 2003 08:49:41 -0500 Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx with esmtp (Exim 4.12) id 1AHO2W-0004Pl-00 for provreg-archive@ietf.org; Wed, 05 Nov 2003 08:49:40 -0500 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA5Da2dF001607 for ; Wed, 5 Nov 2003 14:36:02 +0100 (MET) Received: by nic.cafax.se (8.12.10/8.12.10/Submit) id hA5Da2hc001606 for ietf-provreg-outgoing; Wed, 5 Nov 2003 14:36:02 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA5Da1dF001599 for ; Wed, 5 Nov 2003 14:36:01 +0100 (MET) Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hA5DZxha019977; Wed, 5 Nov 2003 08:36:00 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2657.72) id ; Wed, 5 Nov 2003 08:35:59 -0500 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF01A707FC@vsvapostal8.vasrv.verisign.com> From: "Hollenbeck, Scott" To: "'Antony Perkov'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] RE: Grace periods Date: Wed, 5 Nov 2003 08:35:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I agree, it wouldn't be the right thing to do to have non RGP > stuff in the > existing document without changing it's name. I guess I was > really asking > is there an intent to make it a more general "grace periods" > document. As > you say this may or may not be necessary. No, I wasn't planning on making the document a "grace periods" document. The ones that you described outside of RGP require nothing more than status values to indicate application of a registry policy. RGP has real processing requirements in addition to the status values. One should be able to do RGP without the grace periods (and vice-versa), so I don't think they should be combined in the same namespace (or document). > For clarity, perhaps I should explain my understanding of the > "new" grace > periods suggested in the Deletes Task Force report. It seems > to all boils > down to: a registrar being able to get a credit / refund for > any domain > creation, renewal, or transfer as long as they delete the > domain within 5 > days of the creation, renewal, or transfer (which then leads to the > redemption grace period except during the add grace period). > > To me the "pending" status values don't really seem to describe this > situation adequately to a registrar as they don't distinguish between > "action not finished" and "action refundable". Perhaps... > I guess the most important thing is that all registries > implementing the > Deletes Task Force's suggested grace periods expose this information > consistently. How are other people doing this at the moment? I'm not aware of anyone that has tried expose the grace period information. To be honest, I'm leery when it comes to producing new protocol structures every time some ICANN task force produces a policy recommendation. If, however, others feel that these grace periods are sufficiently well established in a few different TLD registries maybe it makes sense to document them as status values. -Scott- From owner-ietf-provreg@cafax.se Wed Nov 5 09:00:46 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05820 for ; Wed, 5 Nov 2003 09:00:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHODR-0004YG-00 for provreg-archive@ietf.org; Wed, 05 Nov 2003 09:00:57 -0500 Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx with esmtp (Exim 4.12) id 1AHODQ-0004YD-00 for provreg-archive@ietf.org; Wed, 05 Nov 2003 09:00:56 -0500 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA5DoSdF001814 for ; Wed, 5 Nov 2003 14:50:28 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hA5DoRJZ001813 for ietf-provreg-outgoing; Wed, 5 Nov 2003 14:50:27 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA5DoPdF001808 for ; Wed, 5 Nov 2003 14:50:26 +0100 (MET) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.10/8.12.10) with ESMTP id hA5DoGrP014300 for ; Wed, 5 Nov 2003 14:50:16 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: (from jaap@localhost) by bartok.sidn.nl (8.12.10/8.12.10/Submit) id hA5DoFdn014299 for ietf-provreg@cafax.se; Wed, 5 Nov 2003 14:50:15 +0100 (CET) (envelope-from jaap) Received: from popintmanex.int.poptel.net (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA5DFCdF001296 for ; Wed, 5 Nov 2003 14:15:13 +0100 (MET) Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Nov 2003 13:15:07 -0000 Message-ID: From: Antony Perkov To: "Hollenbeck, Scott" , ietf-provreg@cafax.se Subject: RE: [ietf-provreg] RE: Grace periods Date: Wed, 5 Nov 2003 13:15:06 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, I agree, it wouldn't be the right thing to do to have non RGP stuff in the existing document without changing it's name. I guess I was really asking is there an intent to make it a more general "grace periods" document. As you say this may or may not be necessary. For clarity, perhaps I should explain my understanding of the "new" grace periods suggested in the Deletes Task Force report. It seems to all boils down to: a registrar being able to get a credit / refund for any domain creation, renewal, or transfer as long as they delete the domain within 5 days of the creation, renewal, or transfer (which then leads to the redemption grace period except during the add grace period). To me the "pending" status values don't really seem to describe this situation adequately to a registrar as they don't distinguish between "action not finished" and "action refundable". I guess the most important thing is that all registries implementing the Deletes Task Force's suggested grace periods expose this information consistently. How are other people doing this at the moment? Antony. > -----Original Message----- > From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] > Sent: 04 November 2003 12:31 > To: 'Antony Perkov'; 'ietf-provreg@cafax.se' > Subject: [ietf-provreg] RE: Grace periods > > Antony, > > No, I have no intention of updating the RGP document to > include descriptions > of status values that have nothing to do with the RGP. There > may, however, > be some value in defining a new extension that describes some of the > policy-based grace periods that you described below. > > But -- there's already a status value to describe what I > think you mean when > you say "Transfer grace period". See the description of the > "pendingTransfer" status in the domain draft. For that > matter, it may make > sense to use the other "pending" status values to describe > the add and renew > grace periods, as in "this action has been requested but > hasn't yet been > fully completed". Would that make sense? > > -Scott- > > > -----Original Message----- > > From: Antony Perkov [mailto:antony.perkov@poptel.coop] > > Sent: Tuesday, November 04, 2003 6:04 AM > > To: ietf-provreg@cafax.se > > Cc: shollenbeck@verisign.com > > Subject: Grace periods > > > > > > Are there any plans to update the > > draft-hollenbeck-epp-rgp-01.txt document > > to include status values for grace periods other than "redemption"? > > > > I'm interested in status values for the other grace periods > > described at > > http://www.dnso.org/dnso/notes/20030323.DeletesTF-final-report > .html which > are: > > * Add grace period > * Auto renew grace period > * Renew grace period > * Transfer grace period > > It seems to me that it would be useful to be able to provide > registrars this > information via the command. > From owner-ietf-provreg@cafax.se Sun Nov 9 19:06:27 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19590 for ; Sun, 9 Nov 2003 19:06:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIzZn-0002VS-00 for provreg-archive@ietf.org; Sun, 09 Nov 2003 19:06:39 -0500 Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx with esmtp (Exim 4.12) id 1AIzZm-0002VO-00 for provreg-archive@ietf.org; Sun, 09 Nov 2003 19:06:38 -0500 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA9NrldF004866 for ; Mon, 10 Nov 2003 00:53:47 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hA9NrlCc004865 for ietf-provreg-outgoing; Mon, 10 Nov 2003 00:53:47 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA9NrjdF004860 for ; Mon, 10 Nov 2003 00:53:45 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hA9Nrhha000621; Sun, 9 Nov 2003 18:53:43 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2657.72) id ; Sun, 9 Nov 2003 18:53:42 -0500 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF01A70986@vsvapostal8.vasrv.verisign.com> From: "Hollenbeck, Scott" To: "'Antony Perkov'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] RE: Grace periods Date: Sun, 9 Nov 2003 18:53:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk Antony, After thinking about this a bit more I think you might be on to something. It may make more sense to modify this document to make it a general grace period document since the RGP is itself an ICANN-described grace period. It would mean some re-work to make the RGP one of several grace periods, but it might make more sense than having two documents describing different grace periods. I'm at the IETF meeting now if anyone wants to talk about this live. If not, I'll think about it some more and see what I can do next week. -Scott- > -----Original Message----- > From: Antony Perkov [mailto:antony.perkov@poptel.coop] > Sent: Wednesday, November 05, 2003 8:15 AM > To: Hollenbeck, Scott; ietf-provreg@cafax.se > Subject: RE: [ietf-provreg] RE: Grace periods > > > Scott, > > I agree, it wouldn't be the right thing to do to have non RGP > stuff in the > existing document without changing it's name. I guess I was > really asking > is there an intent to make it a more general "grace periods" > document. As > you say this may or may not be necessary. > > For clarity, perhaps I should explain my understanding of the > "new" grace > periods suggested in the Deletes Task Force report. It seems > to all boils > down to: a registrar being able to get a credit / refund for > any domain > creation, renewal, or transfer as long as they delete the > domain within 5 > days of the creation, renewal, or transfer (which then leads to the > redemption grace period except during the add grace period). > > To me the "pending" status values don't really seem to describe this > situation adequately to a registrar as they don't distinguish between > "action not finished" and "action refundable". > > I guess the most important thing is that all registries > implementing the > Deletes Task Force's suggested grace periods expose this information > consistently. How are other people doing this at the moment? > > Antony. > > > -----Original Message----- > > From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] > > Sent: 04 November 2003 12:31 > > To: 'Antony Perkov'; 'ietf-provreg@cafax.se' > > Subject: [ietf-provreg] RE: Grace periods > > > > Antony, > > > > No, I have no intention of updating the RGP document to > > include descriptions > > of status values that have nothing to do with the RGP. There > > may, however, > > be some value in defining a new extension that describes some of the > > policy-based grace periods that you described below. > > > > But -- there's already a status value to describe what I > > think you mean when > > you say "Transfer grace period". See the description of the > > "pendingTransfer" status in the domain draft. For that > > matter, it may make > > sense to use the other "pending" status values to describe > > the add and renew > > grace periods, as in "this action has been requested but > > hasn't yet been > > fully completed". Would that make sense? > > > > -Scott- > > > > > -----Original Message----- > > > From: Antony Perkov [mailto:antony.perkov@poptel.coop] > > > Sent: Tuesday, November 04, 2003 6:04 AM > > > To: ietf-provreg@cafax.se > > > Cc: shollenbeck@verisign.com > > > Subject: Grace periods > > > > > > > > > Are there any plans to update the > > > draft-hollenbeck-epp-rgp-01.txt document > > > to include status values for grace periods other than > "redemption"? > > > > > > I'm interested in status values for the other grace periods > > > described at > > > http://www.dnso.org/dnso/notes/20030323.DeletesTF-final-report > > .html which > > are: > > > > * Add grace period > > * Auto renew grace period > > * Renew grace period > > * Transfer grace period > > > > It seems to me that it would be useful to be able to provide > > registrars this > > information via the command. > > > From owner-ietf-provreg@cafax.se Wed Nov 26 15:58:22 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28060 for ; Wed, 26 Nov 2003 15:58:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP6k6-0004lM-00 for provreg-archive@ietf.org; Wed, 26 Nov 2003 15:58:34 -0500 Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx with esmtp (Exim 4.12) id 1AP6k6-0004lI-00 for provreg-archive@ietf.org; Wed, 26 Nov 2003 15:58:34 -0500 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hAQKkKdF025049 for ; Wed, 26 Nov 2003 21:46:20 +0100 (MET) Received: by nic.cafax.se (8.12.10/8.12.10/Submit) id hAQKkKVL025048 for ietf-provreg-outgoing; Wed, 26 Nov 2003 21:46:20 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hAQKkJdF025043 for ; Wed, 26 Nov 2003 21:46:19 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hAQKkIha012440 for ; Wed, 26 Nov 2003 15:46:18 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2657.72) id ; Wed, 26 Nov 2003 15:46:17 -0500 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF01A52233@vsvapostal8.vasrv.verisign.com> From: "Gould, James" To: "'ietf-provreg@cafax.se'" , "Hollenbeck, Scott" Subject: [ietf-provreg] draft-hollenbeck-epp-rgp-01.txt comments/proposal Date: Wed, 26 Nov 2003 15:46:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, I reviewed draft-hollenbeck-epp-rgp-01.txt and I have the following comments: 1. In the VNDS implementation, RGP does not have a renewal feature, so if RGP was a Command-Response Extension, it would be better suited for the domain:update command than the domain:renew command. 2. Since restore (request & report) functions more as a Protocol Command than a Command-Response Extension, I believe that it is better suited as a Protocol Extension. The namespace and XML schema could support both the restore Protocol Extension and the Command-Response extension for the domain:info response. Based on the proposal of 2, the info response would include the same extension as defined in draft-hollenbeck-epp-rgp-01.txt: S: S: S: S: S: The restore extension would be moved up to a protocol extension with some slight modifications: C: C: C: C: C: OR ... C: C: ABC-12345 C: C: The response would include no element. S: S: S: S: S: Command completed successfully S: S: S: ABC-12345 S: 54321-XYZ S: S: S: By making the rgp:request and rgp:report protocol extensions, there would be no coupling of either domain:update or domain:renew behavior. If anyone else is working on rgp, please respond with your thoughts and comments. Thanks, JG James F. Gould VeriSign Naming and Directory Services jgould@verisign.com From owner-ietf-provreg@cafax.se Wed Nov 26 17:39:27 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01017 for ; Wed, 26 Nov 2003 17:39:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AP8Jw-0005wg-00 for provreg-archive@ietf.org; Wed, 26 Nov 2003 17:39:40 -0500 Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx with esmtp (Exim 4.12) id 1AP8Jv-0005wd-00 for provreg-archive@ietf.org; Wed, 26 Nov 2003 17:39:39 -0500 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hAQMT2dF025794 for ; Wed, 26 Nov 2003 23:29:02 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hAQMT2fK025793 for ietf-provreg-outgoing; Wed, 26 Nov 2003 23:29:02 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hAQMT0dF025788 for ; Wed, 26 Nov 2003 23:29:01 +0100 (MET) Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 1AP89Y-0007wq-00; Wed, 26 Nov 2003 17:28:56 -0500 Message-ID: <3FC5292A.7F9C02B7@libertyrms.info> Date: Wed, 26 Nov 2003 17:28:58 -0500 From: janusz sienkiewicz Organization: LibertyRMS Co. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686) X-Accept-Language: en MIME-Version: 1.0 To: "Gould, James" CC: "'ietf-provreg@cafax.se'" , "Hollenbeck, Scott" Subject: Re: [ietf-provreg] draft-hollenbeck-epp-rgp-01.txt comments/proposal References: <5BEA6CDB196A4241B8BE129D309AA4AF01A52233@vsvapostal8.vasrv.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit I don't see any clear advantage of using Protocol Extension. The fact that rgp is provisioned as an extension of renew command does not mean that renew and rgp behavior should be coupled. To avoid confusion the registry implementation may impose restriction on valid values for period element. It could only accept ZERO value if element is present. Using Protocol Extension approach instead of Command-Response Extension for RGP would make the extension syntax more complex. At least one element should be added to to allow passing domain name that should be restored. I don't agree that the response of would include no element. The response should contain at least domain name and without it can not be accomplished. Janusz Sienkiewicz Please see comments below: "Gould, James" wrote: > Scott, > > I reviewed draft-hollenbeck-epp-rgp-01.txt and I have the following > comments: > > 1. In the VNDS implementation, RGP does not have a renewal feature, so if > RGP was a Command-Response Extension, it would be better suited for the > domain:update command than the domain:renew command. > > 2. Since restore (request & report) functions more as a Protocol Command > than a Command-Response Extension, I believe that it is better suited as a > Protocol Extension. The namespace and XML schema could support both the > restore Protocol Extension and the Command-Response extension for the > domain:info response. > > Based on the proposal of 2, the info response would include the same > extension as defined in draft-hollenbeck-epp-rgp-01.txt: > > S: > S: S: xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0 > S: rgp-1.0.xsd"> > S: > S: > S: > > The restore extension would be moved up to a protocol extension with some > slight modifications: > > C: > C: C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 > C: epp-1.0.xsd"> > C: > C: C: xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0 > C: rgp-1.0.xsd"> > C: OR ... > C: > C: ABC-12345 > C: > C: > > The response would include no element. > > S: > S: S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 > S: epp-1.0.xsd"> > S: > S: > S: Command completed successfully > S: > S: > S: ABC-12345 > S: 54321-XYZ > S: > S: > S: > > By making the rgp:request and rgp:report protocol extensions, there would be > no coupling of either domain:update or domain:renew behavior. > > If anyone else is working on rgp, please respond with your thoughts and > comments. > > Thanks, > > JG > > James F. Gould > VeriSign Naming and Directory Services > jgould@verisign.com From owner-ietf-provreg@cafax.se Sun Nov 30 10:26:36 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03459 for ; Sun, 30 Nov 2003 10:26:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQTTG-0006CL-00 for provreg-archive@ietf.org; Sun, 30 Nov 2003 10:26:50 -0500 Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx with esmtp (Exim 4.12) id 1AQTTF-0006CH-00 for provreg-archive@ietf.org; Sun, 30 Nov 2003 10:26:49 -0500 Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hAUFEudF007280 for ; Sun, 30 Nov 2003 16:14:56 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hAUFEut2007279 for ietf-provreg-outgoing; Sun, 30 Nov 2003 16:14:56 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from smtp.web.de (smtp03.web.de [217.72.192.158]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hAUFEtdF007274 for ; Sun, 30 Nov 2003 16:14:55 +0100 (MET) Received: from [212.202.208.92] (helo=moloko) by smtp.web.de with asmtp (WEB.DE 4.99 #516) id 1AQTHd-0007eO-00 for ietf-provreg@cafax.se; Sun, 30 Nov 2003 16:14:49 +0100 From: "Alexander Peters" To: Subject: [ietf-provreg] could a int or loc postalInfo be removed? Date: Sun, 30 Nov 2003 16:13:38 +0100 Message-ID: <000001c3b754$885e6790$1301a8c0@moloko> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Content-Transfer-Encoding: 7bit Dear all, for example a contact provides local and international postal address information. how could the registrar remove the local information for some reasons? i don't have a concrete use case for this but i was wondering if this may be possible with draft-ietf-provreg-epp-contact-07.txt. is a searchable mailarchive for the provreg list available? Thanks, Alexander Peters Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hAUFEudF007280 for ; Sun, 30 Nov 2003 16:14:56 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hAUFEut2007279 for ietf-provreg-outgoing; Sun, 30 Nov 2003 16:14:56 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from smtp.web.de (smtp03.web.de [217.72.192.158]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hAUFEtdF007274 for ; Sun, 30 Nov 2003 16:14:55 +0100 (MET) Received: from [212.202.208.92] (helo=moloko) by smtp.web.de with asmtp (WEB.DE 4.99 #516) id 1AQTHd-0007eO-00 for ietf-provreg@cafax.se; Sun, 30 Nov 2003 16:14:49 +0100 From: "Alexander Peters" To: Subject: [ietf-provreg] could a int or loc postalInfo be removed? Date: Sun, 30 Nov 2003 16:13:38 +0100 Message-ID: <000001c3b754$885e6790$1301a8c0@moloko> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-provreg@cafax.se Precedence: bulk Dear all, for example a contact provides local and international postal address information. how could the registrar remove the local information for some reasons? i don't have a concrete use case for this but i was wondering if this may be possible with draft-ietf-provreg-epp-contact-07.txt. is a searchable mailarchive for the provreg list available? Thanks, Alexander Peters Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hAQMT2dF025794 for ; Wed, 26 Nov 2003 23:29:02 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hAQMT2fK025793 for ietf-provreg-outgoing; Wed, 26 Nov 2003 23:29:02 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from mail.libertyrms.com ([209.167.124.227]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hAQMT0dF025788 for ; Wed, 26 Nov 2003 23:29:01 +0100 (MET) Received: from dev3.int.libertyrms.com ([10.1.2.204] helo=libertyrms.info) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 1AP89Y-0007wq-00; Wed, 26 Nov 2003 17:28:56 -0500 Message-ID: <3FC5292A.7F9C02B7@libertyrms.info> Date: Wed, 26 Nov 2003 17:28:58 -0500 From: janusz sienkiewicz Organization: LibertyRMS Co. X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.18-3custom i686) X-Accept-Language: en MIME-Version: 1.0 To: "Gould, James" CC: "'ietf-provreg@cafax.se'" , "Hollenbeck, Scott" Subject: Re: [ietf-provreg] draft-hollenbeck-epp-rgp-01.txt comments/proposal References: <5BEA6CDB196A4241B8BE129D309AA4AF01A52233@vsvapostal8.vasrv.verisign.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-provreg@cafax.se Precedence: bulk I don't see any clear advantage of using Protocol Extension. The fact that rgp is provisioned as an extension of renew command does not mean that renew and rgp behavior should be coupled. To avoid confusion the registry implementation may impose restriction on valid values for period element. It could only accept ZERO value if element is present. Using Protocol Extension approach instead of Command-Response Extension for RGP would make the extension syntax more complex. At least one element should be added to to allow passing domain name that should be restored. I don't agree that the response of would include no element. The response should contain at least domain name and without it can not be accomplished. Janusz Sienkiewicz Please see comments below: "Gould, James" wrote: > Scott, > > I reviewed draft-hollenbeck-epp-rgp-01.txt and I have the following > comments: > > 1. In the VNDS implementation, RGP does not have a renewal feature, so if > RGP was a Command-Response Extension, it would be better suited for the > domain:update command than the domain:renew command. > > 2. Since restore (request & report) functions more as a Protocol Command > than a Command-Response Extension, I believe that it is better suited as a > Protocol Extension. The namespace and XML schema could support both the > restore Protocol Extension and the Command-Response extension for the > domain:info response. > > Based on the proposal of 2, the info response would include the same > extension as defined in draft-hollenbeck-epp-rgp-01.txt: > > S: > S: S: xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0 > S: rgp-1.0.xsd"> > S: > S: > S: > > The restore extension would be moved up to a protocol extension with some > slight modifications: > > C: > C: C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > C: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 > C: epp-1.0.xsd"> > C: > C: C: xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0 > C: rgp-1.0.xsd"> > C: OR ... > C: > C: ABC-12345 > C: > C: > > The response would include no element. > > S: > S: S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > S: xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0 > S: epp-1.0.xsd"> > S: > S: > S: Command completed successfully > S: > S: > S: ABC-12345 > S: 54321-XYZ > S: > S: > S: > > By making the rgp:request and rgp:report protocol extensions, there would be > no coupling of either domain:update or domain:renew behavior. > > If anyone else is working on rgp, please respond with your thoughts and > comments. > > Thanks, > > JG > > James F. Gould > VeriSign Naming and Directory Services > jgould@verisign.com Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hAQKkKdF025049 for ; Wed, 26 Nov 2003 21:46:20 +0100 (MET) Received: by nic.cafax.se (8.12.10/8.12.10/Submit) id hAQKkKVL025048 for ietf-provreg-outgoing; Wed, 26 Nov 2003 21:46:20 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hAQKkJdF025043 for ; Wed, 26 Nov 2003 21:46:19 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hAQKkIha012440 for ; Wed, 26 Nov 2003 15:46:18 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2657.72) id ; Wed, 26 Nov 2003 15:46:17 -0500 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF01A52233@vsvapostal8.vasrv.verisign.com> From: "Gould, James" To: "'ietf-provreg@cafax.se'" , "Hollenbeck, Scott" Subject: [ietf-provreg] draft-hollenbeck-epp-rgp-01.txt comments/proposal Date: Wed, 26 Nov 2003 15:46:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, I reviewed draft-hollenbeck-epp-rgp-01.txt and I have the following comments: 1. In the VNDS implementation, RGP does not have a renewal feature, so if RGP was a Command-Response Extension, it would be better suited for the domain:update command than the domain:renew command. 2. Since restore (request & report) functions more as a Protocol Command than a Command-Response Extension, I believe that it is better suited as a Protocol Extension. The namespace and XML schema could support both the restore Protocol Extension and the Command-Response extension for the domain:info response. Based on the proposal of 2, the info response would include the same extension as defined in draft-hollenbeck-epp-rgp-01.txt: S: S: S: S: S: The restore extension would be moved up to a protocol extension with some slight modifications: C: C: C: C: C: OR ... C: C: ABC-12345 C: C: The response would include no element. S: S: S: S: S: Command completed successfully S: S: S: ABC-12345 S: 54321-XYZ S: S: S: By making the rgp:request and rgp:report protocol extensions, there would be no coupling of either domain:update or domain:renew behavior. If anyone else is working on rgp, please respond with your thoughts and comments. Thanks, JG James F. Gould VeriSign Naming and Directory Services jgould@verisign.com Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA9NrldF004866 for ; Mon, 10 Nov 2003 00:53:47 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hA9NrlCc004865 for ietf-provreg-outgoing; Mon, 10 Nov 2003 00:53:47 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA9NrjdF004860 for ; Mon, 10 Nov 2003 00:53:45 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hA9Nrhha000621; Sun, 9 Nov 2003 18:53:43 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2657.72) id ; Sun, 9 Nov 2003 18:53:42 -0500 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF01A70986@vsvapostal8.vasrv.verisign.com> From: "Hollenbeck, Scott" To: "'Antony Perkov'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] RE: Grace periods Date: Sun, 9 Nov 2003 18:53:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk Antony, After thinking about this a bit more I think you might be on to something. It may make more sense to modify this document to make it a general grace period document since the RGP is itself an ICANN-described grace period. It would mean some re-work to make the RGP one of several grace periods, but it might make more sense than having two documents describing different grace periods. I'm at the IETF meeting now if anyone wants to talk about this live. If not, I'll think about it some more and see what I can do next week. -Scott- > -----Original Message----- > From: Antony Perkov [mailto:antony.perkov@poptel.coop] > Sent: Wednesday, November 05, 2003 8:15 AM > To: Hollenbeck, Scott; ietf-provreg@cafax.se > Subject: RE: [ietf-provreg] RE: Grace periods > > > Scott, > > I agree, it wouldn't be the right thing to do to have non RGP > stuff in the > existing document without changing it's name. I guess I was > really asking > is there an intent to make it a more general "grace periods" > document. As > you say this may or may not be necessary. > > For clarity, perhaps I should explain my understanding of the > "new" grace > periods suggested in the Deletes Task Force report. It seems > to all boils > down to: a registrar being able to get a credit / refund for > any domain > creation, renewal, or transfer as long as they delete the > domain within 5 > days of the creation, renewal, or transfer (which then leads to the > redemption grace period except during the add grace period). > > To me the "pending" status values don't really seem to describe this > situation adequately to a registrar as they don't distinguish between > "action not finished" and "action refundable". > > I guess the most important thing is that all registries > implementing the > Deletes Task Force's suggested grace periods expose this information > consistently. How are other people doing this at the moment? > > Antony. > > > -----Original Message----- > > From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] > > Sent: 04 November 2003 12:31 > > To: 'Antony Perkov'; 'ietf-provreg@cafax.se' > > Subject: [ietf-provreg] RE: Grace periods > > > > Antony, > > > > No, I have no intention of updating the RGP document to > > include descriptions > > of status values that have nothing to do with the RGP. There > > may, however, > > be some value in defining a new extension that describes some of the > > policy-based grace periods that you described below. > > > > But -- there's already a status value to describe what I > > think you mean when > > you say "Transfer grace period". See the description of the > > "pendingTransfer" status in the domain draft. For that > > matter, it may make > > sense to use the other "pending" status values to describe > > the add and renew > > grace periods, as in "this action has been requested but > > hasn't yet been > > fully completed". Would that make sense? > > > > -Scott- > > > > > -----Original Message----- > > > From: Antony Perkov [mailto:antony.perkov@poptel.coop] > > > Sent: Tuesday, November 04, 2003 6:04 AM > > > To: ietf-provreg@cafax.se > > > Cc: shollenbeck@verisign.com > > > Subject: Grace periods > > > > > > > > > Are there any plans to update the > > > draft-hollenbeck-epp-rgp-01.txt document > > > to include status values for grace periods other than > "redemption"? > > > > > > I'm interested in status values for the other grace periods > > > described at > > > http://www.dnso.org/dnso/notes/20030323.DeletesTF-final-report > > .html which > > are: > > > > * Add grace period > > * Auto renew grace period > > * Renew grace period > > * Transfer grace period > > > > It seems to me that it would be useful to be able to provide > > registrars this > > information via the command. > > > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA5DoSdF001814 for ; Wed, 5 Nov 2003 14:50:28 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hA5DoRJZ001813 for ietf-provreg-outgoing; Wed, 5 Nov 2003 14:50:27 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from bartok.sidn.nl (bartok.sidn.nl [193.176.144.164]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA5DoPdF001808 for ; Wed, 5 Nov 2003 14:50:26 +0100 (MET) Received: from bartok.sidn.nl (localhost.sidn.nl [127.0.0.1]) by bartok.sidn.nl (8.12.10/8.12.10) with ESMTP id hA5DoGrP014300 for ; Wed, 5 Nov 2003 14:50:16 +0100 (CET) (envelope-from jaap@bartok.sidn.nl) Received: (from jaap@localhost) by bartok.sidn.nl (8.12.10/8.12.10/Submit) id hA5DoFdn014299 for ietf-provreg@cafax.se; Wed, 5 Nov 2003 14:50:15 +0100 (CET) (envelope-from jaap) Received: from popintmanex.int.poptel.net (popintmanex.poptel.org.uk [213.55.9.22]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA5DFCdF001296 for ; Wed, 5 Nov 2003 14:15:13 +0100 (MET) Received: by exchange.poptel.net with Internet Mail Service (5.5.2653.19) id ; Wed, 5 Nov 2003 13:15:07 -0000 Message-ID: From: Antony Perkov To: "Hollenbeck, Scott" , ietf-provreg@cafax.se Subject: RE: [ietf-provreg] RE: Grace periods Date: Wed, 5 Nov 2003 13:15:06 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk Scott, I agree, it wouldn't be the right thing to do to have non RGP stuff in the existing document without changing it's name. I guess I was really asking is there an intent to make it a more general "grace periods" document. As you say this may or may not be necessary. For clarity, perhaps I should explain my understanding of the "new" grace periods suggested in the Deletes Task Force report. It seems to all boils down to: a registrar being able to get a credit / refund for any domain creation, renewal, or transfer as long as they delete the domain within 5 days of the creation, renewal, or transfer (which then leads to the redemption grace period except during the add grace period). To me the "pending" status values don't really seem to describe this situation adequately to a registrar as they don't distinguish between "action not finished" and "action refundable". I guess the most important thing is that all registries implementing the Deletes Task Force's suggested grace periods expose this information consistently. How are other people doing this at the moment? Antony. > -----Original Message----- > From: Hollenbeck, Scott [mailto:shollenbeck@verisign.com] > Sent: 04 November 2003 12:31 > To: 'Antony Perkov'; 'ietf-provreg@cafax.se' > Subject: [ietf-provreg] RE: Grace periods > > Antony, > > No, I have no intention of updating the RGP document to > include descriptions > of status values that have nothing to do with the RGP. There > may, however, > be some value in defining a new extension that describes some of the > policy-based grace periods that you described below. > > But -- there's already a status value to describe what I > think you mean when > you say "Transfer grace period". See the description of the > "pendingTransfer" status in the domain draft. For that > matter, it may make > sense to use the other "pending" status values to describe > the add and renew > grace periods, as in "this action has been requested but > hasn't yet been > fully completed". Would that make sense? > > -Scott- > > > -----Original Message----- > > From: Antony Perkov [mailto:antony.perkov@poptel.coop] > > Sent: Tuesday, November 04, 2003 6:04 AM > > To: ietf-provreg@cafax.se > > Cc: shollenbeck@verisign.com > > Subject: Grace periods > > > > > > Are there any plans to update the > > draft-hollenbeck-epp-rgp-01.txt document > > to include status values for grace periods other than "redemption"? > > > > I'm interested in status values for the other grace periods > > described at > > http://www.dnso.org/dnso/notes/20030323.DeletesTF-final-report > .html which > are: > > * Add grace period > * Auto renew grace period > * Renew grace period > * Transfer grace period > > It seems to me that it would be useful to be able to provide > registrars this > information via the command. > Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA5Da2dF001607 for ; Wed, 5 Nov 2003 14:36:02 +0100 (MET) Received: by nic.cafax.se (8.12.10/8.12.10/Submit) id hA5Da2hc001606 for ietf-provreg-outgoing; Wed, 5 Nov 2003 14:36:02 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA5Da1dF001599 for ; Wed, 5 Nov 2003 14:36:01 +0100 (MET) Received: from vsvapostalgw3.prod.netsol.com (vsvapostalgw3.prod.netsol.com [10.170.12.61]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hA5DZxha019977; Wed, 5 Nov 2003 08:36:00 -0500 (EST) Received: by vsvapostalgw3.prod.netsol.com with Internet Mail Service (5.5.2657.72) id ; Wed, 5 Nov 2003 08:35:59 -0500 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF01A707FC@vsvapostal8.vasrv.verisign.com> From: "Hollenbeck, Scott" To: "'Antony Perkov'" , "'ietf-provreg@cafax.se'" Subject: RE: [ietf-provreg] RE: Grace periods Date: Wed, 5 Nov 2003 08:35:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk > I agree, it wouldn't be the right thing to do to have non RGP > stuff in the > existing document without changing it's name. I guess I was > really asking > is there an intent to make it a more general "grace periods" > document. As > you say this may or may not be necessary. No, I wasn't planning on making the document a "grace periods" document. The ones that you described outside of RGP require nothing more than status values to indicate application of a registry policy. RGP has real processing requirements in addition to the status values. One should be able to do RGP without the grace periods (and vice-versa), so I don't think they should be combined in the same namespace (or document). > For clarity, perhaps I should explain my understanding of the > "new" grace > periods suggested in the Deletes Task Force report. It seems > to all boils > down to: a registrar being able to get a credit / refund for > any domain > creation, renewal, or transfer as long as they delete the > domain within 5 > days of the creation, renewal, or transfer (which then leads to the > redemption grace period except during the add grace period). > > To me the "pending" status values don't really seem to describe this > situation adequately to a registrar as they don't distinguish between > "action not finished" and "action refundable". Perhaps... > I guess the most important thing is that all registries > implementing the > Deletes Task Force's suggested grace periods expose this information > consistently. How are other people doing this at the moment? I'm not aware of anyone that has tried expose the grace period information. To be honest, I'm leery when it comes to producing new protocol structures every time some ICANN task force produces a policy recommendation. If, however, others feel that these grace periods are sufficiently well established in a few different TLD registries maybe it makes sense to document them as status values. -Scott- Return-Path: Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA4CUldF017830 for ; Tue, 4 Nov 2003 13:30:47 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hA4CUl9H017829 for ietf-provreg-outgoing; Tue, 4 Nov 2003 13:30:47 +0100 (MET) X-Authentication-Warning: nic.cafax.se: majordom set sender to owner-ietf-provreg@cafax.se using -f Received: from heron.verisign.com (heron.verisign.com [216.168.237.102]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hA4CUkdF017824 for ; Tue, 4 Nov 2003 13:30:46 +0100 (MET) Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [10.170.12.38]) by heron.verisign.com (8.12.10/8.12.10) with ESMTP id hA4CUjha013752; Tue, 4 Nov 2003 07:30:45 -0500 (EST) Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2657.72) id ; Tue, 4 Nov 2003 07:30:44 -0500 Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF01A70772@vsvapostal8.vasrv.verisign.com> From: "Hollenbeck, Scott" To: "'Antony Perkov'" , "'ietf-provreg@cafax.se'" Subject: [ietf-provreg] RE: Grace periods Date: Tue, 4 Nov 2003 07:30:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Sender: owner-ietf-provreg@cafax.se Precedence: bulk Antony, No, I have no intention of updating the RGP document to include descriptions of status values that have nothing to do with the RGP. There may, however, be some value in defining a new extension that describes some of the policy-based grace periods that you described below. But -- there's already a status value to describe what I think you mean when you say "Transfer grace period". See the description of the "pendingTransfer" status in the domain draft. For that matter, it may make sense to use the other "pending" status values to describe the add and renew grace periods, as in "this action has been requested but hasn't yet been fully completed". Would that make sense? -Scott- > -----Original Message----- > From: Antony Perkov [mailto:antony.perkov@poptel.coop] > Sent: Tuesday, November 04, 2003 6:04 AM > To: ietf-provreg@cafax.se > Cc: shollenbeck@verisign.com > Subject: Grace periods > > > Are there any plans to update the > draft-hollenbeck-epp-rgp-01.txt document > to include status values for grace periods other than "redemption"? > > I'm interested in status values for the other grace periods > described at > http://www.dnso.org/dnso/notes/20030323.DeletesTF-final-report .html which are: * Add grace period * Auto renew grace period * Renew grace period * Transfer grace period It seems to me that it would be useful to be able to provide registrars this information via the command.