Re: RE: draft-hollenbeck-epp-rgp-01.txt comments/proposal

James,
> What we have here are two registries with different requirements for rgp
> (one with a renew feature and one without).

I have been told that Neulevel/Neustar (.BIZ, .US, .CN, .TW operator) has a
<renew> extension for RGP rather than an update.  Perhaps someone from
Neulevel/Neustar on this list can comment more authoritatively.

-Ram
--------------------------------------------------------------
Ram Mohan
Vice President, Business Operations
Chief Technology Officer
Afilias (http://www.afilias.info)
p: 215-706-5700 x103; f: 215-706-5701
e: [email protected]
--------------------------------------------------------------
----- Original Message ----- 
From: "Gould, James" <[email protected]>
To: <[email protected]>
Cc: <[email protected]>; "Hollenbeck, Scott" <[email protected]>
Sent: Tuesday, December 02, 2003 2:09 PM
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt
comments/proposal


> 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
> [email protected]
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Tuesday, December 02, 2003 12:26 PM
> To: [email protected]
> Cc: [email protected]; [email protected]
> 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
>
>