headers
Hollenbeck, Scott | 1 Dec 2003 13:43
Picon
Favicon

RE: draft-hollenbeck-epp-rgp-01.txt comments/proposal

Jim and I had a long talk about his ideas before he sent them to the list.
I encouraged him to do so since I knew others were looking at ways to
implement RGP.

While I don't personally like the idea of adding new command verbs
(extending the protocol) for operations that seem (to me) similar to an
existing operation, I do think that Jim might be right about redemption not
really being an extension of renewal.  I'm thinking about the merits of
changing the extension from the <renew> command to the <update> command.
How would that sit with those of you who care about the RGP?

-Scott-

> -----Original Message-----
> From: Gould, James 
> Sent: Wednesday, November 26, 2003 3:46 PM
> To: 'ietf-provreg <at> cafax.se'; Hollenbeck, Scott
> Subject: 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Gould, James | 1 Dec 2003 15:41
Picon
Favicon

RE: draft-hollenbeck-epp-rgp-01.txt comments/propo sal

Janusz,

I agree that there could be a way in making rgp work as a Command-Response
Extension to renew or any other base command, but I don't believe it is
optimal.  Below is a typical rgp use case with rgp as a renew extension:

1. Domain is auto renewed
2. Domain is deleted putting it the redemption grace period
3. Client submits a renew with the rgp request extension with 0 as the
registration period
4. Client submits a renew with the rgp report with 0 as the registration
period
5. Domain is ok

The use case with rgp as a protocol extension:
1. Domain is auto renewed
2. Domain is deleted putting it in redemption grace period
3. Client submits a rgp request (billable operation)
4. Client submits a rgp report
5. Domain is ok

You are correct that additional attributes and elements would be added to
the protocol extension to include attributes like the domain name.  I did
not fully define the protocol extension, but really only wanted to present
it in theory. The response to the rgp request or report could be extended,
but it is not essential for rgp.  I don't believe submitting two renew
commands to satisfy the use case is as clean as submitting explicit rgp
commands.  

rgp is a perfect example of the use of a protocol extension, since it really
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hollenbeck, Scott | 1 Dec 2003 17:15
Picon
Favicon

RE: could a int or loc postalInfo be removed?

> for example a contact provides local and international postal 
> address information. how could the registrar remove the local
> information for some reasons?
> 
> i don't have a concrete use case for this but i was wondering 
> if this may be possible with draft-ietf-provreg-epp-contact-07.txt. 

You can overwrite the postal information with new data that excludes
whichever form you wish to remove, but there is no way to remove one form or
the other using the "rem" attribute.  You have the change the data using the
"chg" attribute

> is a searchable mailarchive for the provreg list available?

http://www.cafax.se/ietf-provreg/maillist/

You can google the site to search for content.

-Scott-
Permalink | Reply | 0 comments |
headers
janusz sienkiewicz | 1 Dec 2003 18:32

Re: RE: draft-hollenbeck-epp-rgp-01.txt comments/proposal

I agree that Jim might be right about redemption not really being an extension
of renewal. From the other hand rgp as an extension of <renew> command can be
used without any major problems on both server and client side. As a proof of
that already deployed rgp implementations that use <renew> command for rgp
redemption could be used. There are near future plans for additional
deployments of similiar rgp implementations.

I think that unless something is really broken with <renew> approach, rgp
syntax changes that may impact operating clients should be avoided.

Janusz Sienkiewicz

"Hollenbeck, Scott" wrote:

> Jim and I had a long talk about his ideas before he sent them to the list.
> I encouraged him to do so since I knew others were looking at ways to
> implement RGP.
>
> While I don't personally like the idea of adding new command verbs
> (extending the protocol) for operations that seem (to me) similar to an
> existing operation, I do think that Jim might be right about redemption not
> really being an extension of renewal.  I'm thinking about the merits of
> changing the extension from the <renew> command to the <update> command.
> How would that sit with those of you who care about the RGP?
>
> -Scott-
>
Permalink | Reply | 0 comments |
headers
Hollenbeck, Scott | 1 Dec 2003 18:59
Picon
Favicon

RE: RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal

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

If people are already doing RGP as an extended renewal, what are they doing
about the renewal part of the command?

-Scott-
Permalink | Reply | 1 comment |
headers
janusz sienkiewicz | 1 Dec 2003 20:04

Re: RE: draft-hollenbeck-epp-rgp-01.txt comments/proposal

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hollenbeck, Scott | 1 Dec 2003 20:12
Picon
Favicon

RE: RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal

> 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-
Permalink | Reply | 1 comment |
headers
janusz sienkiewicz | 1 Dec 2003 20:29

Re: 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gould, James | 1 Dec 2003 23:15
Picon
Favicon

RE: RE: draft-hollenbeck-epp-rgp-01.txt comments/p roposal

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.  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.  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.  The VNDS rgp does not have
a renew feature, so logically it shouldn't involve a renew command.
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?  

JG

James F. Gould
VeriSign Naming and Directory Services
jgould <at> verisign.com

-----Original Message-----
(Continue reading)

Permalink | Reply | 1 comment |
headers
Michael Young | 2 Dec 2003 00:14

RE: RE: draft-hollenbeck-epp-rgp-01.txt comments/proposal


-----Original Message-----
From: owner-ietf-provreg <at> cafax.se [mailto:owner-ietf-provreg <at> cafax.se] On
Behalf Of Gould, James
Sent: Monday, December 01, 2003 5:16 PM
To: 'janusz sienkiewicz'; Hollenbeck, Scott
Cc: 'ietf-provreg <at> 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
(Continue reading)

Permalink | Reply | 0 comments |

Gmane