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

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 4 May 2015 16:30:15 +0800

Dear all,

CNNIC proposed a EPP reseller extension on the last ROW meeting. Based on this proposal, two drafts were submitted. 

draft-zhou-eppext-reseller is about the reseller extensions of EPP for domain names, hosts and contacts. draft-zhou-eppext-reseller-mapping is a document that describes the EPP reseller object mapping.

Any comments are welcome.

Linlin Zhou
 
From: internet-drafts
Date: 2015-05-04 16:06
To: [email-masked]
Subject: I-D Action: draft-zhou-eppext-reseller-mapping-00.txt
 
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
Pages           : 31
Date            : 2015-05-04
 
Abstract:
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for provisioning and management of registry reseller stored
   in a shared central repository.  Specified in Extensible Markup
   Language (XML), this extended mapping is applied to provide
   additional features required for the provisioning of registry
   resellers.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-zhou-eppext-reseller-mapping/
 
There's also a htmlized version available at:
https://tools.ietf.org/html/draft-zhou-eppext-reseller-mapping-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
 
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
 
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Patrick Mevzek <[email-masked]>
Date: Sun, 24 May 2015 19:13:07 +0200

Hello Linlin, Ning, Chao, Xiaodong and James,

Linlin Zhou <[email-masked]> 2015-05-04 10:28
> 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"?
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…

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

Maybe also add a sentence explaining that it is allowed (or denied) to
have parentId relationship between 2 resellers objects without the
same clID?

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

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

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

- 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

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

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?

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

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

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.

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

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

"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

- the update example has :
   C:          <reseller:disclose flag="1">
   C:            <reseller:voice/>
   C:            <reseller:email/>
   C:          </contact:disclose>

it should be </reseller:disclose> instead.

Regards,

-- 
Patrick Mevzek

---

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 25 May 2015 17:22:41 +0800

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

Regards,
Linlin

> -----原始邮件----- 
> 发件人: "Patrick Mevzek" <[email-masked]> 
> 发送时间: 2015-05-25 01:13:07 (星期一) 
> 收件人: [email-masked] 
> 抄送: 
> 主题: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-mapping-00.txt 
> 
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"?

> again later in the document… 
Yes, this phrase is slightly inaccurate. I'll check it.

> parentId, reseller B must not have reseller A as parentId 
I agree with you that loop should be prohibited. Thanks for the text.

> have parentId relationship between 2 resellers objects without the 
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.

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

> document, which of course does not have a section numbered 2.9 
Sorry. This should be the section 2.9 of [RFC5733].

> so something should be added 
OK.

> for the non-sponsoring client, since voice:email is in the disclose 
Yes, you are correct. I'll remove the email info in the text.

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

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

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

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

> whoisInfo is never used nor described in the text… 
Yes, this should be removed.

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

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

> 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. 
> these later ones should probably be removed 
OK.

> it should be </reseller:disclose> instead. 
Yes.