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

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

Janusz,

I agree that there could be a way in making rgp work as a Command-Response
Extension to renew or any other base command, but I don't believe it is
optimal.  Below is a typical rgp use case with rgp as a renew extension:

1. Domain is auto renewed
2. Domain is deleted putting it the redemption grace period
3. Client submits a renew with the rgp request extension with 0 as the
registration period
4. Client submits a renew with the rgp report with 0 as the registration
period
5. Domain is ok

The use case with rgp as a protocol extension:
1. Domain is auto renewed
2. Domain is deleted putting it in redemption grace period
3. Client submits a rgp request (billable operation)
4. Client submits a rgp report
5. Domain is ok

You are correct that additional attributes and elements would be added to
the protocol extension to include attributes like the domain name.  I did
not fully define the protocol extension, but really only wanted to present
it in theory. The response to the rgp request or report could be extended,
but it is not essential for rgp.  I don't believe submitting two renew
commands to satisfy the use case is as clean as submitting explicit rgp
commands.  

rgp is a perfect example of the use of a protocol extension, since it really
is not a renew or an update, but is a new set of verbs.  By combining verbs
(i.e. rgp with renew, rgp with update) it makes it more of a complex
interface for the clients and makes it a more complex implementation for the
server.  The clients will have to know not to pass specific elements for a
rgp request to work with a renew or an update.  If rgp is defined as a
protocol extension it is defined at the XML schema level.  The server side
only needs a handler per verb, so the handling of rgp is not mixed with any
other operation.  rgp is billable which matches more closely with renew, but
it doesn't extend the registration period which matches more closely with
update.  rgp is not a perfect match for either renew or update.  

The command response extensions are best suited in adding attributes to
existing verbs, but not suited for adding completely new verbs.  If this is
the pattern that will be followed, there is really no purpose for defining
the protocol extension in EPP.       

JG

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


-----Original Message-----
From: janusz@libertyrms.info [mailto:janusz@libertyrms.info] 
Sent: Wednesday, November 26, 2003 5:29 PM
To: Gould, James
Cc: 'ietf-provreg@cafax.se'; Hollenbeck, Scott
Subject: Re: [ietf-provreg] draft-hollenbeck-epp-rgp-01.txt
comments/proposal

I don't see any clear advantage of using Protocol Extension.

The fact that rgp is provisioned as an extension of renew command does not
mean
that renew and rgp behavior should be coupled. To avoid confusion the
registry
implementation may impose restriction on valid values for period element. It
could only accept ZERO value if <rgp:extension> element is present.

Using Protocol Extension approach instead of Command-Response Extension for
RGP
would make the extension syntax more complex. At least one element should be
added to <rgp:restore> to allow passing domain name that should be restored.

I don't agree that the response of <rgp:restore> would include no <resData>
element. The response should contain at least domain name and without
<resData>
it can not be accomplished.

Janusz Sienkiewicz

Please see comments below:

"Gould, James" wrote:

> Scott,
>
> I reviewed draft-hollenbeck-epp-rgp-01.txt and I have the following
> comments:
>
> 1. In the VNDS implementation, RGP does not have a renewal feature, so if
> RGP was a Command-Response Extension, it would be better suited for the
> domain:update command than the domain:renew command.

>
> 2. Since restore (request & report) functions more as a Protocol Command
> than a Command-Response Extension, I believe that it is better suited as a
> Protocol Extension.  The namespace and XML schema could support both the
> restore Protocol Extension and the Command-Response extension for the
> domain:info response.
>
> Based on the proposal of 2, the info response would include the same
> extension as defined in draft-hollenbeck-epp-rgp-01.txt:
>
>    S:    <extension>
>    S:      <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
>    S:       xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
>    S:       rgp-1.0.xsd">
>    S:        <rgp:rgpStatus s="redemptionPeriod"/>
>    S:      </rgp:infData>
>    S:    </extension>
>
> The restore extension would be moved up to a protocol extension with some
> slight modifications:
>
>    C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
>    C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
>    C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>    C:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
>    C:     epp-1.0.xsd">
>    C:  <extension>
>    C:     <rgp:restore xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"
>    C:       xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0
>    C:       rgp-1.0.xsd">
>    C:        <rgp:request/>  OR <rgp:report>...</rgp:report>
>    C:      </rgp:renew>
>    C:    <clTRID>ABC-12345</clTRID>
>    C:  </extension>
>    C:</epp>
>
> The response would include no <resData> element.
>
>   S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
>   S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
>   S:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>   S:     xsi:schemaLocation="urn:ietf:params:xml:ns:epp-1.0
>   S:     epp-1.0.xsd">
>   S:  <response>
>   S:    <result code="1000">
>   S:      <msg>Command completed successfully</msg>
>   S:    </result>
>   S:    <trID>
>   S:      <clTRID>ABC-12345</clTRID>
>   S:      <svTRID>54321-XYZ</svTRID>
>   S:    </trID>
>   S:  </response>
>   S:</epp>
>
> By making the rgp:request and rgp:report protocol extensions, there would
be
> no coupling of either domain:update or domain:renew behavior.
>
> If anyone else is working on rgp, please respond with your thoughts and
> comments.
>
> Thanks,
>
> JG
>
> James F. Gould
> VeriSign Naming and Directory Services
> jgould@verisign.com