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

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

Hi Patrick,
Please see my feedback below.

> -----原始邮件----- 
> 发件人: "Patrick Mevzek" <[e-mail]> 
> 发送时间: 2015-06-02 07:49:27 (星期二) 
> 收件人: "Linlin Zhou" <[e-mail]> 
> 抄送: "[e-mail]" <[e-mail]> 
> 主题: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-mapping-00.txt 
> 
> Linlin Zhou <[e-mail]> 2015-05-25 11:21 
> > > - I'm not sure to successfully parse this sentence: 
> > > "This document describes an Extensible Provisioning Protocol (EPP) 
> > > mapping for provisioning and management of registry reseller stored 
> > > in a shared central repository." 
> > > 
> > > Isn't a word missing somewhere after "stored"? 
> > Accutually I tried to follow the sentences in the introduction section discribed in RFC5731, RFC5732 & RFC5733. I don't quite understand what do you mean by "missing a word"? 
> 
> Yes, but as a mirror of, for example: 
> "mapping for the provisioning and management of Internet domain names 
> stored in a shared central repository" 
> you could have 
> "mapping for provisioning and management of registry reseller *object* 
> (or *info*) stored in a shared central repository" 
> 
Understood.

> > > However this brings additionnal question : 
> > > what happens if reseller:name is in disclose flag=0 and hence should 
> > > not displayed in the result, but since it is 
> > > mandatory per the XML schema ? 
> > The definition of disclosure refers to RFC5733. I think the contact object may have the same issue. Maybe let the registry to decide is the best way to solve this problem. 
> 
> Yes, you are right, I reread RFC5733 and I do not see how disclose 
> could work for a domain:info by a registrar not sponsor of the 
> contacts. 
> 
> I always though that disclose data applies to other kind of accesses, 
> like whois query. I did not think about domain:info 
> 
> But like I said, disclose was added late to the EPP specification, and 
> I'm not sure any registry really uses it in fact. Anyone has more data 
> on that? 
> 
> 
Reread RFC5733 section 2.9,
"...Once set, disclosure preferences can be reviewed using a contact-information query. A server operator MUST reject any transaction that requests disclosure practices that do not conform to the announced data-collection policy with a 2308 error response code."
The disclosure example you mentioned may fit this scenario.
 
"Client-identification features provided by the EPP <login> command and contact-authorization information are used to determine if a client is authorized to perform contact-information query commands.
 These features also determine if a client is authorized to receive data that is otherwise marked for non-disclosure in a query response."
A registrar infos a contact, it should provide authentication information. If this is not provided or is invalid, server policy determines if the command is rejected or if response information will be returned to the client.

> > > also, more a matter of taste, but why having name/org/street/etc… data 
> > > attached directly to the reseller object? 
> > > why not put that in a contact, like type "main" or whatever and just 
> > > put the contact id? 
> > > This would simplify everything a lot, instead of having to redefine 
> > > all elements already present in the contact-1.0 namespace 
> > > 
> > > In any case I have not double checked, but I hope that the 
> > > contact/postalInfo & so have the same XML definitions in the reseller 
> > > schema than in the contact schema. 
> > > 
> > Supposing we define a main contact to put these information, if this contact is a admin contact of a domain as well, the contact may have different disclose data collection policy defined in domain mapping and reseller mapping seperately. 
> 
> How so? 
> I'm not sure to understand you there, the disclose is a property of a 
> contact, if it is used both as a "reseller" contact and as a domain 
> name contact, then the same disclose will apply to both. And if the 
> registrar would like to have separate disclose policies, he would need 
> to have 2 separate contacts. 
I don't think it is a good idea to have two identical contacts information with different id only. A contact must be assigned to a particular reseller but could not be referenced by other objects.
We consider that a reseller is much more like a registrar. It could have contact attribute, such as admin contact, billing contact, and have its own postal information.

Regards,
Linlin