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

["Michael Young" <[e-mail]>]

James thank you for clarifying that the intent of this thread is solve a
cross-protocol registry/registrar implementation issue with RGP.  While I am
indeed in favour of trying to accommodate the general issue, this working
group has not been a forum for solving RRP to EPP issues to date.  Many of
us have had RRP to EPP interoperability issues to solve for, and generally
speaking, the focus of provreg has been not been to work on cross-protocol,
cross registry issues.  The basis for clear argument for reworking EPP draft
approaches has been based on EPP issues alone.

Having said that I agree there is a worthwhile problem to solve,(its only
going to make registrars life easier if we implement consistently) but I
don't think this is the correct forum.  I am happy to take the RGP
discussion off-line with Scott and yourself and see if we can come up with a
reasonable approach to the issue - so we can end this thread and not end up
with contending drafts down the line.  
     
Michael Young

 
-----Original Message-----
From: Gould, James [mailto:[e-mail]] 
Sent: December 3, 2003 12:56 PM
To: 'Michael Young'; [e-mail]
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt comments/p
roposal

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
[e-mail]


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Michael Young
Sent: Wednesday, December 03, 2003 10:32 AM
To: 'Patrick'; [e-mail]
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: [e-mail] [mailto:[e-mail]] On
Behalf Of Patrick
Sent: December 3, 2003 7:30 AM
To: [e-mail]
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.''