To:
"Gould, James" <JGould@verisign.com>, <janusz@libertyrms.info>
Cc:
<ietf-provreg@cafax.se>, "Hollenbeck, Scott" <shollenbeck@verisign.com>
From:
"Ram Mohan" <rmohan@afilias.info>
Date:
Tue, 2 Dec 2003 18:03:05 -0500
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] 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: rmohan@afilias.info -------------------------------------------------------------- ----- Original Message ----- From: "Gould, James" <JGould@verisign.com> To: <janusz@libertyrms.info> Cc: <ietf-provreg@cafax.se>; "Hollenbeck, Scott" <shollenbeck@verisign.com> 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 > jgould@verisign.com > > > -----Original Message----- > From: janusz@libertyrms.info [mailto:janusz@libertyrms.info] > Sent: Tuesday, December 02, 2003 12:26 PM > To: JGould@verisign.com > Cc: ietf-provreg@cafax.se; shollenbeck@verisign.com > 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 > >