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

[janusz sienkiewicz <janusz@libertyrms.info>]

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