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

"Linlin Zhou" <zhoulinlin@cnnic.cn> Tue, 25 August 2015 02:09 UTC

Return-Path: <zhoulinlin@cnnic.cn>
X-Original-To: eppext@ietfa.amsl.com
Delivered-To: eppext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297791A8A3D for <eppext@ietfa.amsl.com>; Mon, 24 Aug 2015 19:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.611
X-Spam-Level:
X-Spam-Status: No, score=-4.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EYAwZQEMj8m for <eppext@ietfa.amsl.com>; Mon, 24 Aug 2015 19:09:19 -0700 (PDT)
Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 144091A899B for <eppext@ietf.org>; Mon, 24 Aug 2015 19:09:18 -0700 (PDT)
Received: from Foxmail (unknown [218.241.111.73]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0B5gZVOzttVUGu9Bw--.9004S2; Tue, 25 Aug 2015 10:09:18 +0800 (CST)
Date: Tue, 25 Aug 2015 10:10:52 +0800
From: Linlin Zhou <zhoulinlin@cnnic.cn>
To: Marc Groeneweg <Marc.Groeneweg@sidn.nl>, "eppext@ietf.org" <eppext@ietf.org>
References: <2015070314245253820930@cnnic.cn>, <24A9E532-D16B-4227-83A4-A16E05533734@sidn.nl>, <2015082510095068904623@cnnic.cn>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 5, 136[cn]
Mime-Version: 1.0
Message-ID: <2015082510105250354726@cnnic.cn>
Content-Type: multipart/alternative; boundary="----=_001_NextPart855674801661_=----"
X-CM-TRANSID: AQAAf0B5gZVOzttVUGu9Bw--.9004S2
X-Coremail-Antispam: 1UD129KBjvJXoW3Ww48ZFW8XFWkAw1kXFy5Jwb_yoW7AFyDpa y3Xr47trsYyFsFy3yIv3W8X3WrAr9Yv3y7JFs0qr1Uta15GF12vr4jkFs8uFyUCr9av3WY qFWjv3sxCa1UZFJanT9S1TB71UUUUUJqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUQ2b7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4 vEx4A2jsIEc7CjxVAFwI0_Cr1j6rxdM2kKe7AKxVWUXVWUAwAS0I0E0xvYzxvE52x082IY 62kv0487Mc02F40En4AKxVAvwIkv4cxYr24l5I8CrVCF0I0E4I0vr24lYx0E2Ix0cI8IcV AFwI0_JrI_JrylYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG 0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xvF2IEb7IF0Fy26I8I3I1lc7CjxV Aaw2AFwI0_JF0_Jw1lc2xSY4AK67AK6r4UMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCj c4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4 CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1x MIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Zr0_Wr 1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr1l6VAC Y4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxU4knYDUUUU
X-CM-SenderInfo: p2kr3zplqox0w6fq0xffof0/
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/bCOjHV2KIHqpwGDvzD6y8JEtWLA>
Subject: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-mapping-01.txt
X-BeenThere: eppext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <eppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eppext>, <mailto:eppext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eppext/>
List-Post: <mailto:eppext@ietf.org>
List-Help: <mailto:eppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eppext>, <mailto:eppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Aug 2015 02:09:22 -0000

Sorry, please ignore this letter. I have not finished my reply.



Linlin Zhou
 
From: Linlin Zhou
Date: 2015-08-25 10:09
To: Marc Groeneweg; eppext@ietf.org
Subject: Re: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-mapping-01.txt
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; eppext@ietf.org
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