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

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

Mike,

What I meant by making the renew feature subordinate to the rgp command is
that as with transfer, create, and renew, there is the ability to specify
the registration period.  If rgp has an optional renew feature, than it to
should have the ability to specify the registration period.  I did not mean
to make an rgp renew command, but to simply add an optional <rgp:period>
element to allow for it.  

By latching a completely different action (i.e. rgp:report) to an existing
one (i.e. domain:renew, domain:update, or domain:delete) the only thing that
is being reused might be the verb name and maybe one or two other
attributes.  The reuse of the verb doesn't make sense since it doesn't
really match the intent of the new action and the reuse of the attribute
still leaves open what to do with the attributes that are not reused (i.e.
ignore, report error).  A command-response extension is perfect for adding
attributes that weren't previously defined, but not for changing the entire
meaning of the action.  Sending an rgp:report with a domain:renew is a good
example of a misuse of a command-response extension, since it has absolutely
nothing to do with renew.    

When I reviewed the EPP specifications and saw the Protocol Extension, I
believed that it was the answer for these kinds of problems.  As I stated
before, rgp could be implemented as an extension to any one of the standard
commands, but this is like writing a single doIt function that takes a large
number of arguments were the values make sense in one context but not in
another.  I prefer the OO concept of adding a new method.

Based on this thread, I need clarification of a best practice for use of the
EPP Protocol Extension.  I have another extension that I'm considering
making a Protocol Extension, based on the same reasoning.  It looks like
sticking with the existing verbs is preferred by some over adding new ones.


Any comments from the Registrars?


JG

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


-----Original Message-----
From: Michael Young [mailto:myoung@libertyrms.info] 
Sent: Monday, December 01, 2003 6:15 PM
To: 'Gould, James'; 'janusz sienkiewicz'; 'Hollenbeck, Scott'
Cc: ietf-provreg@cafax.se
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt
comments/proposal



-----Original Message-----
From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On
Behalf Of Gould, James
Sent: Monday, December 01, 2003 5:16 PM
To: 'janusz sienkiewicz'; Hollenbeck, Scott
Cc: 'ietf-provreg@cafax.se'
Subject: RE: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt
comments/proposal

Scott & Janusz,

I agree that specifying a period of zero is cleaner if the renew command is
extended for rgp.  

I still believe that the command-response extension is the wrong way to go
for rgp.  Server functions would have to be updated to differentiate between
a standard renew and an rgp (request & report) renew.

MY- I don't see why this is more effort that introducing a new command.

If verb extensions are made by extending either renew or update, than the
registry has to make
policy decisions related to what standard attributes to ignore or report
errors on.  

MY- that problem exists in EPP implementations already - we have to deal
this already - no added burden there.

I prefer making the validation more explicit using an XML
schema.  Morphing a renew or update into an rgp request or rgp report is
mixing verbs that really don't belong together.  

-MY since the whole RGP implementation is essentially a settlement action;
it seems perfectly reasonable to extend either the renew or delete commands
as they are associated with the transactions that lead (or don't lead)to the
settlement action.  Renew is a better choice as its less overloaded than the
delete command. I don't see a valid argument here for burdening registrars
with a new command.  

The VNDS rgp does not have
a renew feature, so logically it shouldn't involve a renew command.

-MY I still don't see how this is relevant to the discussion, if anything
its driving the argument to extend the delete command which I am sure no one
wants to do.

Similarly, while a domain is in pendingDelete status we don't allow any
updates to it, but if rgp is mixed with an update than what do we do about
the specified updates?  If we disallow all updates for an rgp command, than
there is no point in making it an extension of the update command.
If rgp has a renew feature, make the renew function subordinate to the rgp
request command and not the other way around.  If rgp is not a good
candidate for a protocol extension than what is?  

-MY If your argument is that extending renew is confusing to registrars,
then how do you defend suggesting an RGP specific renew command - you don't
think that one renew command plus an extension renew command under an RGP
command is not a little more difficult to follow - this is re-inventing the
wheel just to make it round again.  There are implementations in place using
the renew command extensions; I don't see the point in revisiting this with
these arguments.  They are not compelling enough to warrant starting this
thread all over again. 


-Michael Young



JG

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


-----Original Message-----
From: owner-ietf-provreg@cafax.se [mailto:owner-ietf-provreg@cafax.se] On
Behalf Of janusz sienkiewicz
Sent: Monday, December 01, 2003 2:29 PM
To: Hollenbeck, Scott
Cc: 'ietf-provreg@cafax.se'
Subject: Re: [ietf-provreg] RE: draft-hollenbeck-epp-rgp-01.txt
comments/proposal

I also prefer required zero value for RGP situations. Such behavior would
improve interoperatibility of RGP implementations.

Janusz Sienkiewicz


"Hollenbeck, Scott" wrote:

> > The wording for <renew> command in rgp draft document could
> > be modified to
> > indicate that the absence of period element in <renew> part
> > or value ZERO
> > should indicate that renewal should not be a part of rgp
> > restore. Another
> > option would be to force server to ignore the value of
> > <period> element and
> > assume certain value.
>
> I've thought about the zero value being appropriate here.  It's certainly
an
> approach.
> > > If people are already doing RGP as an extended renewal,
> > what are they doing
> > > about the renewal part of the command?
> >
> > I am aware of one implementation that just ignores the value
> > of <period>
> > element and assumes ZERO if rgp extension is present.
>
> Oooh, accepting a non-zero value and ignoring it isn't a very good idea.
> That would make data reconciliation very difficult in the future if one
> tries to reconcile a non-zero-period <renew> command that was processed
> without error, but with no change to the expiration date.  I'd rather
> require a period of zero for RGP situations.

>
>
> -Scott-