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

[janusz sienkiewicz <janusz@libertyrms.info>]

Please see comments below:

"Hollenbeck, Scott" wrote:

> > I think that unless something is really broken with <renew>
> > approach, rgp
> > syntax changes that may impact operating clients should be avoided.
>
> But:
>
> 1. We're talking about an Internet-Draft (meaning "implement at your own
> risk!"), and an individual submission that hasn't been commented on very
> broadly at that.
>
> 2. I think we need to come up with something that we can all implement the
> same way to maximize interoperability opportunities.
>
> Part of what I think is broken is that redemption should not necessarily
> require an implicit renewal.  I prefer the idea of "redeem via update" and
> then "renew if necessary".  That's two commands, but it's two commands that
> are doing very different things.

I think "renew if necessary" approach is more flexible than "redeem via
update". I covers situations when rgp restore involves renewals and situation
when it does not. Approach "redeem via update" does not offer such flexibility
it assumes that renewal will never be a part of rgp restore.

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.


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


>
>
> -Scott-

Janusz Sienkiewicz