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

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

Dear Marc,
Thanks for your review. Please see my reply inline with the beginning of [Linlin].

Regards,


Linlin Zhou
 
From: Marc Groeneweg
Date: 2015-08-24 20:26
To: Linlin Zhou; [e-mail]
Subject: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-mapping-01.txt
Dear Linlin,

Herewith, as promised, my feedback on the draft proposal on the reseller object:

General: why is this draft called draft-zhou-eppext-reseller-mapping instead of draft-zhou-eppext-reseller? This is meant to be the specification of the reseller object?
And as such, wouldn't the current draft-zhou-eppext-reseller be the draft-zhou-eppext-reseller-ext? As it is the description of the extensions for reseller to other objects?
    [Linlin] It seems like a good idea that could make the drafts more clear by the names. pherhaps I'm good at naminig drafts.

Section 3.3. Reseller State
Isn’t it a good idea to use the same states for reseller as is for contacts? So something like this:
“   A reseller object MUST always have at least one associated status
   value.  Status values can be set only by the client that sponsors a
   reseller object and by the server on which the object resides.  A
   client can change the status of a reseller object using the EPP
   <update> command.  Each status value MAY be accompanied by a string
   of human-readable text that describes the rationale for the status
   applied to the object.

   A client MUST NOT alter status values set by the server.  A server
   MAY alter or override status values set by a client, subject to local
   server policies.  The status of an object MAY change as a result of
   either a client-initiated transform command or an action performed by
   a server operator.

   Status values that can be added or removed by a client are prefixed
   with "client".  Corresponding status values that can be added or
   removed by a server are prefixed with "server".  Status values that
   do not begin with either "client" or "server" are server-managed.

   Status Value Descriptions:

   -  clientDeleteProhibited, serverDeleteProhibited
      Requests to delete the object MUST be rejected.

   -  clientUpdateProhibited, serverUpdateProhibited
      Requests to update the object (other than to remove this status)
      MUST be rejected.

   -  linked
      The contact object has at least one active association with
      another object, such as a domain object.  Servers SHOULD provide
      services to determine existing object associations.

   -  ok
      This is the normal status value for an object that has no pending
      operations or prohibitions.  This value is set and removed by the
      server as other status values are added or removed.
,and further” with a paragraph title 3.3. Status Values?
This way, you stay close to the other object specifications within EPP. Don’t you agree?
    [Linlin] 

Section 4.1.2. EPP <info> command
There is a space that should be omitted directly under the example: "The < reseller:infData>". It should be "The <reseller:infData>”.

When using the general accepted State Velues, the line <reseller:state> should be more like this:
"- One or more <reseller:status> elements that describe the status of the reseller object.”

At SIDN, we use a specific element <reselller:tradingName> for identifying the organisational name of the reseller. This is, as I believe, also the case with the reseller extension used by Nominet.
As such, we don’t use a <reseller:postalInfo> element, but only a <reseller:address> element. In your specification you can have one or two name elements for the same reseller, because you can have one or two <reseller:postalInfo> elements. Which name element should one pick? I strongly suggest to use a construction of a more general approach to the name, such as SIDN or Nominet uses.

At SIDN, the <reseller:email> element is deemed to be optional, as is the case with the general <contact:email> element. Make it mandatory by registry policy, not by schema definition.
I suggest to explicitly refer the <reseller:url> to a URL, like "A <reseller:url> element that contains the URL to the website of the reseller”.

What is the benefit of using a contact object within the reseller? Have you seen a real use case for this? Otherwise, I suggest to drop this from your specifications.

A question regarding the deletion of a reseller object: can one delete a reseller object when it is used as a parentID to other reseller objects? Does it delete all associations for underlying objects, or must one first delete the child references?

When I read section  4.2.5 <reseller:update> I came up with the question if a registrar object exists in your registry system. At SIDN, a registrar is a normal contact, so no roles a defined within this object, as is seemingly the case with your definition of a reseller. Roles are solely used at domain level with appropriate references to the contact identifiers. Can you give any clarifications on this?

Further, I think you’ve done a great job in starting a discussion on standardising the reseller object, which is used by some registries. I hope we can achieve a real standard on this, in which all registries can comply to.

Regards,
Marc Groeneweg