RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal

"Michael Young" <myoung@libertyrms.info> Wed, 03 December 2003 15:43 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 KAA20419 for <provreg-archive@ietf.org>; Wed, 3 Dec 2003 10:43:52 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ARZAc-00039a-00 for provreg-archive@ietf.org; Wed, 03 Dec 2003 10:44:07 -0500
Received: from nic.cafax.se ([192.71.228.17]) by ietf-mx with esmtp (Exim 4.12) id 1ARZAc-00039X-00 for provreg-archive@ietf.org; Wed, 03 Dec 2003 10:44:06 -0500
Received: from nic.cafax.se (localhost [127.0.0.1]) by nic.cafax.se (8.12.10/8.12.10) with ESMTP id hB3FWGdF017272 for <ietf-provreg-outgoing@nic.cafax.se>; Wed, 3 Dec 2003 16:32:16 +0100 (MET)
Received: by nic.cafax.se (8.12.10/8.12.10/Submit) id hB3FWGeB017271 for ietf-provreg-outgoing; Wed, 3 Dec 2003 16:32:16 +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 hB3FWFdF017258 for <ietf-provreg@cafax.se>; Wed, 3 Dec 2003 16:32:15 +0100 (MET)
Received: from [10.1.2.195] (helo=DUN435) by mail.libertyrms.com with esmtp (Exim 3.22 #3 (Debian)) id 1ARYz8-0002f2-00; Wed, 03 Dec 2003 10:32:14 -0500
From: Michael Young <myoung@libertyrms.info>
To: 'Patrick' <pat+ietf@patoche.org>, ietf-provreg@cafax.se
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal
Date: Wed, 03 Dec 2003 10:32:10 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
thread-index: AcO5mvCl/MDHyxriRH663fi204M7bQAFb+oA
In-Reply-To: <20031203122940.GC17279@nohope.patoche.org>
Message-Id: <E1ARYz8-0002f2-00@mail.libertyrms.com>
Sender: owner-ietf-provreg@cafax.se
Precedence: bulk
Content-Transfer-Encoding: 7bit

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.''