RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
"Gould, James" <JGould@verisign.com> Wed, 03 December 2003 18:08 UTC
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26551 for <provreg-archive@ietf.org>; Wed, 3 Dec 2003 13:08:20 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARbQS-0005VU-00 for provreg-archive@ietf.org; Wed, 03 Dec 2003 13:08:36 -0500
Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx with esmtp (Exim 4.12) id 1ARbQQ-0005VR-00 for provreg-archive@ietf.org; Wed, 03 Dec 2003 13:08:35 -0500
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3HtjdF018708 for <ietf-provreg-outgoing@nic.cafax.se>; Wed, 3 Dec 2003 18:55:45 +0100 (MET)
Received: from localhost (localhost [[UNIX: localhost]]) by nic.cafax.se (8.12.10/8.12.10/Submit) id hB3HtjEf018707 for ietf-provreg-outgoing; Wed, 3 Dec 2003 18:55:45 +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 hB3HthdF018702 for <ietf-provreg@cafax.se>; Wed, 3 Dec 2003 18:55:43 +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 hB3Htgha029475; Wed, 3 Dec 2003 12:55:42 -0500 (EST)
Received: by vsvapostalgw1.prod.netsol.com with Internet Mail Service (5.5.2657.72) id <XL5QAK1H>; Wed, 3 Dec 2003 12:55:42 -0500
Message-ID: <5BEA6CDB196A4241B8BE129D309AA4AF01A5224B@vsvapostal8.vasrv.verisign.com>
From: "Gould, James" <JGould@verisign.com>
To: 'Michael Young' <myoung@libertyrms.info>, ietf-provreg@cafax.se
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
Date: Wed, 03 Dec 2003 12:55:40 -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
Mike, You have a working version of the existing specification in a single registry. The .com/.net ICANN agreement for RGP does not allow for a renew feature or any updates for that matter while a domain has a redemption status. You can look at RRP as a reference for how it is handled in another running registry, which is not by extending the renew command. For the rgp extension to be a standard across registries it needs to support the basic set of requirements across all registries. I believe it to be unintuitive for our Registrars to send rgp commands via a domain:renew. The fact that you implemented to the current version of the specification does not make it a defacto standard. Changes can and will occur as more registries implement RGP via EPP. Just look at what has happened from EPP 00 to EPP 09. We implemented to different versions of EPP knowing that it would change based on community input. I would like to hear from the silent majority. These are the same set of Registrars that have to integrate with other registries including the VNDS registries. JG James F. Gould VeriSign Naming and Directory Services jgould@verisign.com -----Original Message----- From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Michael Young Sent: Wednesday, December 03, 2003 10:32 AM To: 'Patrick'; ietf-provreg@cafax.se Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal Hi Patrick, You don't specifiy that you actually have implemented RGP via the renew command extension for any registries. Given that you state its been six months since you implemented epp clients, it seems you couldn't have done so for RGP(renew ext approach) which came in later than that. Also we have a silent majority of well over a hundred registrars that are using RGP via the renew command extension today. I have yet to see any registrars come into the list and specifically say they have a desire to reimplement the current EPP approach to RGP. The gains in adopting a new command for the community at large are not greater than the efforts to redeploy an entirely new approach in EPP registries when an adequate/workable approach exists. After all we are talking about EPP concerns in this group, not RRP concerns. I go back to a simple statement. "If it aint broke, don't fix it." Michael Young -----Original Message----- From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On Behalf Of Patrick Sent: December 3, 2003 7:30 AM To: ietf-provreg@cafax.se Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal On Tue, Dec 02, 2003 at 02:09:30PM -0500, Gould, James took time to write: > Any Registrar feedback? The three options right now include: I am not working in a Registrar right now, but was 6 months ago, and hope to be soon again. I implemented RRP & EPP clients for 5 registries back then, and still working on this open source project. > RGP as renew command-response extension. The typical use case is: > 1. Domain is auto renewed > 2. Registrar deletes Domain via a <domain:delete> 3. Registrar sends a > <domain:renew> with a <domain:period> of 0 (supporting a period is > registry specific) with the rgp request extension 4. Registrar sends a > <domain:renew> with a <domain:period> of 0 with the rgp report > extension 5. Domain is ok (I find the domain:period=0 to be a awful hack) [..] > RGP as protocol extension. The typical use case is: > 1. Domain is auto renewed > 2. Registrar deletes Domain via a <domain:delete> 3. Registrar sends > an <rgp:request> with an optional <rgp:period> element. > 4. Registrar sends an <rgp:report> > 5. Domain is ok For me, this is the cleaner way, since RGP is a totally new feature. We could imagine that it is used for contacts[1], for example, and then domain:renew would not apply easily. Ditto for any other objects managed at the Registry. [1] with new requirements to check contacts' validity, we can imagine that someone would like to work as: when a contact is not validated, delete it, but then provide the functionnality of a restore, as a last chance. -- Patrick. ``Never argue with an idiot. He'll drag you down to his level, then beat you with experience.''
- RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… Hollenbeck, Scott
- Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… janusz sienkiewicz
- RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… Hollenbeck, Scott
- Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… janusz sienkiewicz
- RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… Gould, James
- RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… Michael Young
- RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… Gould, James
- RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… Gould, James
- Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… Ram Mohan
- Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… Patrick
- RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… Michael Young
- Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… Patrick
- RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… Michael Young
- RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… Gould, James
- Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… janusz sienkiewicz
- RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… Gould, James
- RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… Michael Young
- RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… Hollenbeck, Scott
- Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-0… janusz sienkiewicz