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

From: "Gould, James" <[email-masked]>
Date: Wed, 26 Nov 2003 15:46:17 -0500

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
[email-masked]

---

From: janusz sienkiewicz <[email-masked]>
Date: Wed, 26 Nov 2003 17:28:58 -0500

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: