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

From: Patrick Mevzek <[email-masked]>
Date: Tue, 2 Jun 2015 01:49:27 +0200

Linlin Zhou <[email-masked]> 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"

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

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

-- 
Patrick Mevzek

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 2 Jun 2015 14:09:43 +0800

Hi Patrick,
Please see my feedback below.

> -----原始邮件----- 
> 发件人: "Patrick Mevzek" <[email-masked]> 
> 发送时间: 2015-06-02 07:49:27 (星期二) 
> 收件人: "Linlin Zhou" <[email-masked]> 
> 抄送: "[email-masked]" <[email-masked]> 
> 主题: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-mapping-00.txt 
> 
Understood.

> I'm not sure any registry really uses it in fact. Anyone has more data 
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.

> 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