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

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

Hi Patrick,
Following is my feedback. Thanks for reviewing.

Regards,
Linlin

> -----原始邮件----- 
> 发件人: "Patrick Mevzek" <[e-mail]> 
> 发送时间: 2015-05-25 01:13:07 (星期一) 
> 收件人: [e-mail] 
> 抄送: 
> 主题: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-mapping-00.txt 
> 
> Hello Linlin, Ning, Chao, Xiaodong and James, 
> 
> Linlin Zhou <[e-mail]> 2015-05-04 10:28 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories. 
> > 
> > 
> > Title : Extensible Provisioning Protocol (EPP) Reseller Mapping 
> > Authors : Linlin Zhou 
> > Ning Kong 
> > Chao Qi 
> > Xiaodong Lee 
> > James Gould 
> > Filename : draft-zhou-eppext-reseller-mapping-00.txt 
> 
> I'm implementing it in my opensource EPP client and I have the 
> following comments/questions: 
> 
> - 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"?

> Why are you speaking about "registry reseller" where resellers depend 
> on registrars (which is exactly what you descrive in section 1)? 
> You have again "registry resellers" on the next sentence. But never 
> again later in the document… 
> 
Yes, this phrase is slightly inaccurate. I'll check it.

> - "3.4. Parent Identifier" 
> There should be a sentence prohibiting loops: if reseller A has B as 
> parentId, reseller B must not have reseller A as parentId 
> 
I agree with you that loop should be prohibited. Thanks for the text.

> Maybe also add a sentence explaining that it is allowed (or denied) to 
> have parentId relationship between 2 resellers objects without the 
> same clID? 
> 
Generally speaking, the N-tier reseller and its child reseller usually have the same clID. In my opinion, I try not to specify the policy on the parentID relationship in this extension.  A registry could decide whether or not to support it.

> - comparing with the resellerext I-D, I find it that what is called 
> "resID" there is called only "id" here. I would recommand to use the 
> same node name in both case, since it is the same underlying data. 
> I would prefer "id" everywhere. 
> Same for "resName" vs "name". I would favor "name" everywhere. 
> 
We first conducted the resellerext I-D draft. Then with a deep discussion, the reseller object mapping is felt also necessary. As you mentioned the object naming, we should consider the consistency between the two drafts.
 
> - reseller state: to be more inline with the rest of core EPP I would 
> advise to use the "status" node name, instead of "state" 
> 
> also to stretch things a little more and use standards statuses, 
> why not 'inactive' instead of 'terminated' and 
> 'serverUpdateProhibited' instead of 'readonly'? 
> 
Our original intention is to avoid the confusion with the core EPP status element. So the element name and values are all diffenrent from the core EPP. 
I think 'serverUpdateProhibited' may have the similar meaning with 'readonly'. But 'terminated' means query and tranform commands of a particular reseller are prohibited, while 'inactive' is a status value descibed in RFC5731 to indicate that no delegation information is associated with the object. We feel that they are not totally the same in our understanding.

> - "3.6. Disclosure of Data Elements and Attributes 
> 
> This document supports the same disclosure features described in 
> Section 2.9 of with the use of the <reseller:disclose> element. 
> [RFC5733]." 
> 
> There is probably a wording issue there. In all cases, the online 
> version has an hyperlink on "Section 2.9" pointing to the same 
> document, which of course does not have a section numbered 2.9 
> 
Sorry. This should be the section 2.9 of [RFC5733].

> - in the reseller:info response : 
> "Zero or more OPTIONAL <reseller:contact> elements" : there is no 
> explanation on the "type" attribute which is there in the XML schema, 
> so something should be added 
> 
OK.

> - for the second XML example in 4.1.2, I believe that the voice:email 
> should not be there, if I understand correctly what should happen 
> for the non-sponsoring client, since voice:email is in the disclose 
> flag=0 node 
Yes, you are correct. I'll remove the email info in the text.

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

> also, should the disclose element be seen by the non sponsoring 
> client? (it helps him to see if an element is absent because it is 
> optional or because it is withdrawn due to the disclose policy) 
> 
The disclose element should not be seen by non-sponsoring client. Thanks for pointing it out.

> I believe that the current consensus around disclose in EPP is 
> that it does not work well. AFAIK no registry really use it. 
> Is it really useful to add it for these new reseller objects? 
> 
We agree that 'disclose' is not highly adopted by registries and may add additional complexity. 'Disclosure' is not the key part for reseller mapping. Actually we hope to find some other feasible and acceptable methods to implement data collection policy in WG discussion.

> - §4.2 first paragraph says 
> "<transfer> to manage 
> reseller-object sponsorship changes" 
> while later we read : 
> 4.2.4. EPP <transfer> Command 
> 
> Transfer semantics do not apply to reseller objects, so there is no 
> mapping defined for the EPP <transfer> command. 
> 
> So are transfers possible or not ? 
> 
> Also I believe that the 2nd paragraph of §4.2 has no value there. It 
> seems to be a copy and paste from RFC5731, I do not see its 
> value/relation to this reseller I-D. 
> 
The transfer command is not supported in this extension. I'll update the words in the first paragraph.
To keep consist with other core EPP, the sencond paragraph is added here. I think reseller is an object similar with contact, the transform process should be the same. So I suggest retaining it.

> - create operation 
> 
> XSD schema has for discloseType : 
> <element name="url" minOccurs="0"/> 
> <element name="whoisInfo" minOccurs="0"/> 
> <element name="contact" minOccurs="0"/> 
> 
> whoisInfo is never used nor described in the text… 
> 
Yes, this should be removed.

> 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. This may  add extra complexity for registries to implement the reseller extension.
In addition, the reseller postalInfo is not totally the same with the one defined in RFC5733. The 'org' element is removed. We do not think that a reseller would be an individual that is not represented by an orgnization.

> - delete 
> "A reseller object SHOULD NOT be deleted if it is associated with 
> other known objects." 
> Does that sentence apply to the parentId (meaning that a delete for a 
> reseller that is used as parentId by other resellers would be denied) 
> ? 
> Or to other associations? 
> In that later cases, there should be more details since I believe the 
> document does not speak about any other kind of associations regarding 
> reseller objects. 
> Or is there a relationship with the resellerext I-D, where a given 
> reseller ID may be tied to a domain? 
> 
One possible situation is the N-tier reseller relationship. The other is the reseller associated with a domain, host or contact object specified in resellerext I-D.

> - update 
> the addRemType has 
> maxOccurs="3" 
> why ? 
> I see the create one has the same, but there is no explanations on 
> that value anywhere. 
> It is either 1 admin contact and 1 billing mandatory, in which case it 
> should be maxOccurs="2" in both cases, or is it up registry policy to 
> define amount of contacts, in which case you should not have a 
> maxOccurs at all? 
> The schema specifies admin tech and billing as valid types, but it is 
> not defined which are mandatory and which are optional? Is this 
> completely under registry policy? 
> 
The XML schema is as follows, 3 types of contact are defined, so the maxOccurs is 3..
<simpleType name="contactAttrType">
    <restriction base="token">
      <enumeration value="admin"/>
      <enumeration value="billing"/>
      <enumeration value="tech"/>
    </restriction>
   </simpleType>
 We do not want to specify which one is mandatory. According to your question, we could remove the manOccurs limitation. 
> 
> "A <reseller:chg> element contains the following OPTIONAL child 
> elements." 
> 
> but then later on you repeat OPTIONAL for some child elements, so 
> these later ones should probably be removed 
> 
OK.

> - the update example has : 
> C: <reseller:disclose flag="1"> 
> C: <reseller:voice/> 
> C: <reseller:email/> 
> C: </contact:disclose> 
> 
> it should be </reseller:disclose> instead. 
> 
Yes.