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 completed 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 not 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] 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 existing EPP. The state value refer to https://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping-05#section-5.4.1.1.  We will consider this problem and discuss the status values in mailing list.

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>”.
    [Linlin] Thanks. This space should be deleted.
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.”
    [Linlin] See the second answer.

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.
    [Linlin] Could you please give me a simple example of the postal info elements used in SIDN and Nominet which could help me better understand your proposal?

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.
    [Linlin] In RFC5733, the <contact:email> is not optional. Please refer to section 3.1.2 and section 4 for detailed information.
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”.
    [Linlin] OK.

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.
    [Linlin] We thought that the reseller object is similar with the domain object. So a reseller may have different types of contacts. This element is required as zero or more. You can choose to add it or not.

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?
    [Linlin] The text "A reseller object SHOULD NOT be deleted if it is associated with other known objects. An associated reseller SHOULD NOT be deleted until associations with other known objects have been broken. " Do you think this is sufficient to clarify your question?

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?
    [Linlin] I'm sorry that I don't understand this problem very well. I guess you mean how does a registrar have a relationship with a reseller. The parentId of a reseller should have a refernce to its corresponding registrar's 'contact identifier'. Just like the domain object does.  

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.
    [Linlin] Thank you.

Regards,
Marc Groeneweg