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


To: Andrew Sullivan <andrew@ca.afilias.info>
Cc: ietf-provreg@cafax.se
From: Edward Lewis <Ed.Lewis@Neustar.biz>
Date: Fri, 22 Jul 2005 09:57:32 -0400
In-Reply-To: <20050722132532.GA26140@libertyrms.info>
Sender: owner-ietf-provreg@cafax.se
Subject: Re: [ietf-provreg] EPP Document Updates

At 9:25 -0400 7/22/05, Andrew Sullivan wrote:
>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.

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.

Home | Date list | Subject list