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

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

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Edward Lewis
> Sent: Tuesday, July 19, 2005 4:45 PM
> To: Andrew Sullivan
> Cc: [email-masked]
> Subject: Re: [ietf-provreg] EPP Document Updates
> 
> At 16:28 -0400 7/19/05, Andrew Sullivan wrote:
> 
> >I can say for sure that we have found some pending states convenient
> >for some cases.  It's particularly useful in ccTLDs, where there can
> >be an elaborate process review prior to a domain really being
> >created or updated or whatever.  You don't want to hold up the
> >protocol while you determine whether (for instance) a registrant has
> >the rights to a domain in that geographic region.  (One can think
> >what one wants about the utility of such policies; but it does seem
> >to be the policy in some places.)
> 
> Pending states are definitely useful.  I don't think anyone wants to 
> remove them from the protocol.
> 
> You are right (in text I removed) that preventing other actions while 
> in pendingDelete is questionable.  That's what we ought to seek to 
> change.

I think that's perfectly appropriate.  If implementation experience has
demonstrated that it was a mistake, we can change it.  The question,
though, is what to replace it with?  No restrictions?  Some
restrictions?  Trying to define a set might be a problem.  Not defining
any in the protocol might be better, since that gives registries the
flexibility to do whatever is appropriate in their own operating
environments.

-Scott-

---

From: Edward Lewis <[email-masked]>
Date: Tue, 19 Jul 2005 23:18:39 +0200 (MEST)

>flexibility to do whatever is appropriate in their own operating

That's what I was thinking.  Is the prohibition (or any prohibition) 
are "business rule" that can be forced up the stack?  Is there a 
reason the protocol needs to define this - is it an interoperability 
issue?

Can a registrar deal with one registry that prohibits one action 
during a pendingDelete and still deal with another registry that 
permits the same action?   I think that's one question which will say 
whether we need to retain the prohibition.

Another aspect is the impact on the document, the code complying to 
it, and whether the schema is changed.

I don't have answers myself right now, but these are the things that 
need looking into.  In my opinion.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

If you knew what I was thinking, you'd understand what I was saying.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Jul 2005 00:41:12 +0200 (MEST)

> reason the protocol needs to define this - is it an interoperability 

Well, some people have argued as much to me.  I sort of don't see it,
though: if there's no implicit restriction from pending*, then the
other server*Prohibited status values are the ones to use, and it's
totally obvious from looking at the status values what you may and
may not do.  Of course, this complicates status handling.  Maybe
that's the reason people wanted the implicit effects -- they think it
is easier to code.

> whether we need to retain the prohibition.

I've been assuming that you don't get to prohibit stuff implicitly
under the changed rules: if you want a prohibition, use the right
prohibited status.  Again, as I've said, I'm not perfectly sure about
this yet, although I haven't come up with a good argument against it. 

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110