Subject: RE: [ietf-provreg] EPP Document Updates

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 19 Jul 2005 23:30:27 +0200 (MEST)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Tuesday, July 19, 2005 4:29 PM
> To: [email-masked]
> Subject: Re: [ietf-provreg] EPP Document Updates
> 
> On Tue, Jul 19, 2005 at 02:47:50PM -0400, Hollenbeck, Scott wrote:
> > Thanks for the thoughts, Ed.
> > 
> > > I talked this over with the developers in-house - I'd (we'd) 
> > > recommend altering the pendingDelete rule (first option).
> > 
> > That's what I originally intended with 3915, but it may mean a text
> > change to 3731 to ensure that the intention is clear.  Not 
> necessarily a
> > big deal.
> 
> Something that isn't clear to me -- and I know that Janusz disagrees
> with me about this, and I'm not even sure what I think about it
> myself -- but why does the pendingDelete status prevent other changes
> on a domain?  If you want to prevent updates, why not add
> serverUpdateProhibited too?  (The same goes for other pending status
> values, and other objects.)

More memory taxation...

The pendingDelete status (originally PENDING-DELETE) has been in the
specs since the very first individual submission.  The restriction went
in between -04 and -05 of the working group versions.  I just spent a
few minutes looking through the archives from 2002 to see what (if
anything) was discussed, but a quick glance didn't turn up anything.

I *think* the idea was that someone (maybe me after talking to
registrars) wanted pendingDelete to be a final, irrevocable "warning"
period before a domain would become available for re-registration.  Once
the removal process started, it should be hard or impossible to prevent
it from completing.

I agree that the transform restriction seems to be kludgy in and of
itself.  The protocol already includes features to prevent transforms,
if desired by the registry, by adding status values as Andrew suggests
above.

In short, I believe that the right thing is to remove the "pendingDelete
prevents transforms" restriction from 3731.

-Scott-

---

From: James Gould <[email-masked]>
Date: Wed, 20 Jul 2005 00:05:23 +0200 (MEST)

I agree with Scott, that the right thing to do is to remove the
"pendingDelete prevents transforms" restriction from 3731 since there is a
use case with RFC 3915 that a transform operation can occur when the domain
has the pendingDelete status.

In the case of RFC 3915 the pendingDelete status is broken into more fine
grained statuses where the combination of pendingDelete and
rgp:pendingDelete will prohibit future transform operations.  The base
specification should either be less specific to allow extensions or registry
policy to define behavior, or the extension should be able to explicitly
override a restriction defined in the base specification.  So removing the
restriction from RFC 3731 would allow RFC 3915 to extend the meaning of the
pendingDelete status, while leaving the restriction requires the extension
to redefine the restriction.  A registry implementing the extension will
follow the policy of both the base specification and the extension.  I don't
believe that it is confusing to registrars that a transform operation is
allowed while a domain has the pendingDelete status knowing that the
registry implements RFC 3915.

-- 

JG 

James F. Gould
VeriSign Naming and Directory Services
[email-masked]

This message is intended for the use of the individual or entity to which it
is addressed, and may contain information that is privileged, confidential
and exempt from disclosure under applicable law. Any unauthorized use,
distribution, or disclosure is strictly prohibited. If you have received
this message in error, please notify sender immediately and destroy/delete
the original transmission

> From: "Hollenbeck, Scott" <[email-masked]>
> Date: Tue, 19 Jul 2005 17:30:47 -0400
> To: Andrew Sullivan <[email-masked]>, <[email-masked]>
> Subject: RE: [ietf-provreg] EPP Document Updates
>

---

From: "Michael Young" <[email-masked]>
Date: Wed, 20 Jul 2005 00:28:32 +0200 (MEST)

Andrew's question of the need for the transform restriction and Scott's
comments as to why it was introduced leave me in support of removing it from
the base specification. A lot has changed (namely RGP) since the restriction
was originally introduced, so it seems like its not fulfilling its original
intent.    

Michael Young
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of James Gould
Sent: Tuesday, July 19, 2005 6:05 PM
To: Hollenbeck, Scott; Andrew Sullivan; [email-masked]
Subject: Re: [ietf-provreg] EPP Document Updates

-- 

JG 

James F. Gould

> specs since the very first individual submission.  The restriction 
> went in between -04 and -05 of the working group versions.  I just 
> spent a few minutes looking through the archives from 2002 to see what 
> (if
> period before a domain would become available for re-registration.  
> Once the removal process started, it should be hard or impossible to 
> prevent it from completing.
> 
> In short, I believe that the right thing is to remove the 
> "pendingDelete prevents transforms" restriction from 3731.
> 
> -Scott-
> 
>

---

From: janusz <[email-masked]>
Date: Thu, 21 Jul 2005 22:08:42 +0200 (MEST)

>prevents transforms" restriction from 3731.
Will removing transform restrictions on pendingDelete remove all 
conflicts between 3731 and 3915?

Lets consider a scenario when a deletion policy prohibits any updates of 
domain objects between enetering pendingDelete state and rgp restore 
request. If serverUpdateProhibited status is used then rgp restore 
request should not be accepted because it is an extension of <update> 
command. From the other hand I don not see any mechanism within EPP 
protocol to protect the domain object from client updates and at the 
same time allowing <update> requests with rgp restore extension.

The "conflict" I described is not as severe as the original one but it 
can be treated as an inconsistency between 3731 and 3915 documents. The 
inconsistency could be removed if rgp restore was defined as a new EPP 
command versus an extension to <update> command.

regards,

Janusz Sienkiewicz