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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 22 Jul 2005 13:20:04 +0200 (MEST)

> -----Original Message-----
> From: janusz [mailto:[email-masked]] 
> Sent: Thursday, July 21, 2005 4:10 PM
> To: Hollenbeck, Scott
> Cc: Andrew Sullivan; [email-masked]
> Subject: Re: [ietf-provreg] EPP Document Updates
> 
> Hollenbeck, Scott wrote:
> 
> >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.
> >
> >
> >  
> >
> Will removing transform restrictions on pendingDelete remove all 
> conflicts between 3731 and 3915?

It will if the registry doesn't do something stupid to introduce a
potential conflict.

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

Yes, a new EPP command could prevent this scenario.  Unfortunately, it's
inconsistent with the guidance presented in RFC 3735.  If we're going to
modify both 3731 and 3915 (and I'm suggesting that we should) we have an
opportunity to write text to ensure that the protocol and the
ICANN-defined policy are consistent.

-Scott-

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 22 Jul 2005 15:25:42 +0200 (MEST)

> > same time allowing <update> requests with rgp restore extension.

It seems to me, though, that Janusz is pointing to another difficulty
that I've also noticed: the *UpdateProhibited status values are too
coarse.

I understand the value of consistency: we have one type of
prohibition against (for instance) <domain:delete>; so we should
similarly have one type of prohibition against other commands, like
<domain:update>.

The trouble I have with this is that <domain:delete> really has only
one function: either it causes a delete to be initiated (and maybe
completed) against a domain, or it does not.  It therefore makes
sense that a client or repository should either prohibit deletes, or
not.

In contrast to that, <domain:update> can change all manner of
attributes on a domain.  Moreover, there are certainly cases where we
want one update to be possible, but not others.  Afilias has had
cases where we wanted (for example) to prevent contact data
associated with a domain from changing; but that didn't mean we
wanted nameserver information not to change, or that we thought it'd
be a bad thing for people to be able to update their authInfo to
something slightly more tough to guess than "1234".

I wonder if the answer is to make some of the update prohibitions
more granular?  I know it's sort of ugly, but it's consistent with
the use-cases we've actually seen.

A

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

---

From: Edward Lewis <[email-masked]>
Date: Fri, 22 Jul 2005 15:57:28 +0200 (MEST)

>the use-cases we've actually seen.

Does this need to be done in the protocol?  (One of my litmus test questions.)

I.e., assuming the domain's contact info is locked but the name 
servers are not.    If a request comes in to change the contact info, 
the response could be that the domain is locked.  Changing name 
servers is okay.  Trying to do both gets a locked notification even 
though the request is half good.

The last situation would be somewhat confusing to the client-side. 
Do you think it is better to make the update prohibitions more 
granular, add an explanation (defined by business rules), or let this 
confusion fall to customer support?

EPP is intertwined with "business rules."  There's a fat grey line 
between what EPP has to do because of business rules and what EPP 
ought to be agnostic about in the business rules.  That's why I'm 
asking.  The subtext is that (IMHO) when we developed EPP the 
community involved had similar business rules, and the rules then 
were still in formation.  Although EPP meets its need well, perhaps 
there are rough edges we missed.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: Fri, 22 Jul 2005 17:11:39 +0200 (MEST)

> Does this need to be done in the protocol?  (One of my litmus test 

I think it has to be _possible_ in the protocol, anyway; and today, I
think, it isn't.  (I may be wrong, of course.  I'm always happy to be
corrected.)

> though the request is half good.

I think my example didn't come across well.  When we want to prevent
(say) registrant data from changing, we must do two things:

1.	Set the serverUpdateProhibited status on the contact object,
so that the contacts name, org, address, &c. can't change.

2.	Set the serverUpdateProhibited status on the domain object,
so that it's not possible to change the registrant's contact id to
something else.

(2) is what's troublesome in this case: the domain is now in a state
where not only the registrant can't be changed; the sponsoring client
can't update the nameservers, either.

This sort of thing happens during "landrush" periods all the time,
for example.  There is a potential for a lot of thrashing during that
period.  I'm perfectly aware that people can be doing naughty things
behind the veil of unchanging contact data; but I can't do anything
about that.  What I can do, in order to solve trademark disputes and
reduce the UDRP invocation, is to make sure that whatever the contact
data is, it isn't changing around daily, making the challenges
invalid.  But while we're waiting for the lawyers to settle things
amongst themselves, there's no reason that the domain should't
resolve, or that the authInfo shouldn't be updated, &c.

"Landrush" cases aren't the only ones that are relevant.  CcTLDs
often have a lot of complicated rules about geographic location that
control what eligible registrants are for a given region.  The sTLDs
under ICANN rules also have complicated eligibility requirements.  So
I think there is a set of business rules here that is currently at
least very hard, if not impossible, to implement under the current
documents.

A

----

---

From: janusz <[email-masked]>
Date: Fri, 22 Jul 2005 17:13:26 +0200 (MEST)

>ICANN-defined policy are consistent.

Perhaps it would be worthwhile to take a look at 3735 to include a 
provision to handle this type of scenarios.

The sample scenario with deletion policy could point to a larger class 
of cases. A registry implementer may try to extend EPP protocol to 
support a new policy. The EPP extension guidelines defined in RFC 3735 
may indicate that an extension to existing EPP command should be chosen. 
From the other hand the policy may require accepting the extension when 
a relevant prohibited status is set.

It may not be obvious to all EPP implementers how the protocol should be 
extended in cases of conflict between 3735 and policy requirements.

Janusz Sienkiewicz

---

From: janusz <[email-masked]>
Date: Fri, 22 Jul 2005 17:39:52 +0200 (MEST)

>the use-cases we've actually seen.

Introduction of more granular update prohibited status values without 
breaking <update> command into a set of corresponding lower granulity 
<update> commands would break existing protocol structure. Currently 
there is a direct link between each prohibited status and EPP command. 
The main purpose of each prohibited status is to indicate that the 
corresponding EPP command should fail on any object that has the status 
value set. The direct link between prohibited statuses and EPP commands 
has positive implication on client and server implementations of the 
protocol. After breaking updateProhibited status into lower granulity 
statues without breaking <update> command the link will be broken. The 
use of the protocol for automated  processing will be more difficult. It 
will be less obvious to the client and server to determine whether a 
particular command can be provisioned or not. The syntax of XML requests 
will have  to be compared against the state of  domain objects to make  
such decisions.

I can see some value of breaking updatedProhibited status into a set of 
more specific prohibited status values provided that <update> command is 
also broken into a set of corresponding more specific commands however I 
am aware that would be a drastic and controversial protocol change.

Janusz