Re: [eppext] I-D Action: draft-zhou-eppext-reseller-00.txt

["Linlin Zhou" <[e-mail]>]

Hi James,

Thanks for your feedback.

> -----原始邮件----- 

> I would match the resellerext:resName element of draft-zhou-eppext-reseller with the reseller:name element of draft-zhou-eppext-reseller-mapping, which is of type contact:postalLineType.  Within draft-zhou-eppext-reseller  I would directly define the resName type in the schema in place of creating a dependency to the contact mapping.  For example: 
> <element name="resName" type=“resellerext:resNameType"/> 
> <simpleType name=“resNameType"> 
> <restriction base="normalizedString"> 
> <minLength value="1"/> 
> <maxLength value="255"/> 
> </restriction> 
> </simpleType> 
> 
Yes, this is the revised resName xml schema.

> 
...
> > > - I'm not sure to understand completely the update case. 
> > > In short, in my understanding, I would expect that there would be a 
> > > sentence stating that "only one add, or rem or chg element is 
> > > permitted", so that there are not mix of add/rem/chg, because in that 
> > > later case it would be difficult to understand what happens. 
> > > Also in that case there should be explanations on what happens when 
> > > the registrar does an add where the domain already has a reseller (for 
> > > me that should be rejected, because a registrar should do a chg in 
> > > that case), and what happens for a del where the domain has no 
> > > reseller (this could be handled as a noop), and what happens for a chg 
> > > where there is no reseller for now (this should be rejected) 
> > > 
> > Yes, this should be "only one" element, I'll make it explicitely. 
> > The three examples you mentioned should be rejected. Error codes defined in RFC5730 should be included in the response. 
> 
> This could be simplified by just supporting a <resellerext:update> element that takes the <resellerext:resID> element along with the optional <resellerext:resName> element to set or replace the existing value and with the support for an empty <resellerext:update> element to clear or remove the reseller as in <resellerext:update xmlns:resellerext=“urn:ietf:params:xml:ns:resellerext-1.0”/>.  The semantics of add and remove really don’t apply if there is a one to one relationship between the provisioning object and the reseller.   
> 
I agree with you that this method is more simplified. I'll consider updating the text.

Regards,
Linlin