To:
"'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>, "Hollenbeck, Scott" <shollenbeck@verisign.com>
From:
"Gould, James" <JGould@verisign.com>
Date:
Wed, 26 Nov 2003 15:46:17 -0500
Sender:
owner-ietf-provreg@cafax.se
Subject:
[ietf-provreg] draft-hollenbeck-epp-rgp-01.txt comments/proposal
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