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

["Gould, James" <JGould@verisign.com>]

Janusz,

When initially discussing this with Scott, my thought was that RGP could
apply to more objects than just domains.  I know of other provisioned
objects that could benefit from an RGP like feature (i.e. E-mail
Forwarding).  In this, RGP would become another verb that that could be
extended by command mappings similar to the core verbs (i.e. Domain RGP and
E-mail Forwarding RGP) each with elements specific to each object.  From a
purest perspective this made sense, but I felt it was too complicated for
now.  By combining the object, in this case domain, with the protocol
extension, I don't believe it invalidates the use of the protocol extension
for adding a new verb.     

My intention of the initial e-mail was to propose the concept of the rgp
protocol extension and not to define the final specification.  Elements like
<rgp:domain> and <rgp:period> could easily be added, since it would have its
own XML schema.  

I disagree with your assertion that a protocol extension should not be
directly associated with existing object mappings.  Since you are defining a
new verb, you can define exactly what objects it applies to.  This could be
an extensible object like described in the first paragraph or it could be a
specific object like domain.  Since domain is the predominate object for
EPP, limiting the verbs to check, create, update, info, renew, delete, and
transfer is too limiting. 

I hope some Registrars are following this so that we get their feedback.
What we have here are two registries with different requirements for rgp
(one with a renew feature and one without).  If the specification is going
to be registry independent it should support both cleanly.  I don't like
coupling rgp with update based on my previous comments related to confusion
of what update elements should be accepted, but for me an update would match
better than a renew.  In our case, no updates are allowed during the
redemption period.    

Any Registrar feedback?  The three options right now include:

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

RGP as update 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:update> with no updates (supporting update
elements is registry specific) with the rgp request extension
4. Registrar sends a <domain:renew> with no updates (supporting update
elements is registry specific) with the rgp report extension
5. Domain is ok

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

The command-response extension to the <domain:info> still applies with all
three options.  

JG

James F. Gould
VeriSign Naming and Directory Services
jgould@verisign.com


-----Original Message-----
From: janusz@libertyrms.info [mailto:janusz@libertyrms.info] 
Sent: Tuesday, December 02, 2003 12:26 PM
To: JGould@verisign.com
Cc: ietf-provreg@cafax.se; shollenbeck@verisign.com
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt
comments/proposal 

James,

I don't think protocol extension offers more clarity than command response
extension. In the first approach the verb is provided in explicit way but
the object the verb is releted to is missing. Looking at the syntax you
attached it is not obvious that <rgp:restore> is a domain related
operation. In the second approach the object is clearly defined but the
verb is defined in implicit manner.

The protocol extension approach is more difficult to implement. With this
approach the rgp syntax will be more complex. The samples you attached to
your original proposal are incorrect and they offer very simplistic view
of necessary changes to rgp draft document. I pointed that out in my first
response. More complex rgp syntax can be used as a rough but objective
measure for determining amount of efforts required for implementing a
particular approach. Subjective references to a particular server
implementation attempts SHOULD NOT be used as a such measure.

You said in one of your responses in the thread that if protocol extension
is not adopted for rgp then "there is really no purpose for defining the
protocol extension in EPP". I disagree with that judgment. An example for
a usefull application of protocol extension would a be a new verb that is
not directly associated with existing object mappings. Something like poll
or hello command.

Janusz Sienkiewicz