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

[Patrick Mevzek <[e-mail]>]

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