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

["Michael Young" <myoung@libertyrms.info>]

-----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-