[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: ietf-provreg@cafax.se
From: Andrew Sullivan <andrew@ca.afilias.info>
Date: Fri, 22 Jul 2005 11:11:29 -0400
Content-Disposition: inline
In-Reply-To: <a06200701bf06a9517f16@[10.31.32.164]>
Mail-Followup-To: Andrew Sullivan <andrew@ca.afilias.info>,ietf-provreg@cafax.se
Reply-To: Andrew Sullivan <andrew@ca.afilias.info>
Sender: owner-ietf-provreg@cafax.se
User-Agent: Mutt/1.5.9i
Subject: Re: [ietf-provreg] EPP Document Updates

On Fri, Jul 22, 2005 at 09:57:32AM -0400, Edward Lewis wrote:
> Does this need to be done in the protocol?  (One of my litmus test 
> questions.)

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

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

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

----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<andrew@ca.afilias.info>                              M2P 2A8
                                        +1 416 646 3304 x4110


Home | Date list | Subject list