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

"Linlin Zhou" <> Fri, 20 November 2015 02:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id ECCA01A1E0E for <>; Thu, 19 Nov 2015 18:33:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.185
X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.585, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e-zHg6FX1deS for <>; Thu, 19 Nov 2015 18:33:47 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4EE8A1A1DE1 for <>; Thu, 19 Nov 2015 18:33:45 -0800 (PST)
Received: from zll (unknown []) by (Coremail) with SMTP id AQAAf0B5gDh_hk5WKRogCA--.17678S2; Fri, 20 Nov 2015 10:33:35 +0800 (CST)
Date: Fri, 20 Nov 2015 10:34:30 +0800
From: Linlin Zhou <>
To: Rik Ribbers <>, nkong <>, "" <>
References: <>, <>
X-Priority: 3
X-Has-Attach: no
X-Mailer: Foxmail 7, 2, 5, 136[cn]
Mime-Version: 1.0
Message-ID: <>
Content-Type: multipart/alternative; boundary="----=_001_NextPart765487284341_=----"
X-CM-TRANSID: AQAAf0B5gDh_hk5WKRogCA--.17678S2
X-Coremail-Antispam: 1UD129KBjvJXoWxKr4furWxuF1rZrWxWFy8Xwb_yoWxJF43pF WfKr43Gr4kAaykCws2vF10g3WFyr90v3yrJrn8Gw1qya45GFyjgr1rKa15ZFyUC3s8tw4j vr4j9w1YkFs5ZrJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUm214x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26F1j6w1UM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4U JVWxJr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I8E87Iv6xkF7I0E14v26F 4UJVW0owAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E42I26xC2a48xMc02F40Ex7xS 67I2xxkvbII20VAFz48EcVAYj21lYx0E2Ix0cI8IcVAFwI0_Jrv_JF1lYx0Ex4A2jsIE14 v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACjI8F5VA0II8E 6IAqYI8I648v4I1lFcxC0VAYjxAxZF0Ew4CEw7xC0wACY4xI67k04243AVC20s07MxkIec xEwVAFwVW8JwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02 F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF 1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7Cj xVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI 0_Jr0_Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JwCE64xvF2IEb7IF0Fy7YxBIdaVF xhVjvjDU0xZFpf9x0JUdl19UUUUU=
X-CM-SenderInfo: p2kr3zplqox0w6fq0xffof0/
Archived-At: <>
Subject: Re: [eppext] I-D Action: draft-zhou-eppext-reseller-mapping-02.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: EPPEXT <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Nov 2015 02:33:51 -0000

Hi Rik,
Thanks for your comments. Please see my feedback inline.

Linlin Zhou
From: Rik Ribbers
Date: 2015-11-06 09:07
To: Linlin Zhou; Ning Kong <>;
Subject: Re: [eppext] I-D Action: draft-zhou-eppext-reseller-mapping-02.txt
Hello Linlin,

Like stated in the WG I’ve collected my comments on the mapping draft.

Section 3.1 

- Add a clarification sentence "All reseller objects are identified by a server-unique identifier" (same as the reseller extension draft)
[Linlin] Ok. This should be added.

Section 3.3

- The Reseller state; I would have expected the epp statusses there. During the WG-meeting there were different opinions here. My preference would be to use epp statussen as a reseller in this draft is modelled as a fullblown EPP object. I'm curious to hear what other people think on this. If we decide not to go for app statuses I will request a subset of status values to match our implementation (I know at least one but have to check for others).
[Linlin] Yes, I would like also hear more about others' opinions, epp status, subset of epp status or some customized status? Could you provide your status examples?

- The reseller draft states that a reseller can be referenced (optionally) by a name. In the XML structure there is no name at the highest level, only at add the postalInfo level. As a postal info can occur more then once in the xml there is no way to identify which name to use. This was addressed in the WG session and there are 2 possible solutions:
    1 remove the name in the reseller draft as it is optional. 
    2 add the name to the reseller object in this draft; The only thing to consider is do we need the name at the postalInfo level then.
I'd prefer option 1, but I can live with option 2
[Linlin] I also think option 1 is a simple solution to this issue.

- the XSD; with all EPP schemas there is a schemaLocation attribute (see domain an contact RFCs) I don't see them in the XSDs here. Allthough it is an optional field I would put them there for consistency reasons.
[Linlin] Actually I didn't find the schemaLocation attribute in RFC5731 and 5733. Could you help give me some hint?

- the XSD; I would strongly recommend reusing XML Type from other EPP objects if available. There are several Types in the XSD which are already available in the other existing XSD, why not reuse them. Escpecially when there is already a dependancy on the contact xsd in there. Below a list of type which are candidates for replacing. The list is probably longer.
    * contactAddrType --> reuse from domain-1.0.xsd 
    * contactType     --> reuse from domain-1.0.xsd (depends on contactAddrType)
    * postalInfoType  --> could be reused from contact-1.0.xsd depending on how the name referencing issue is resolved (see remark below)
    * addrType        --> reuse from contact-1.0.xsd
    * discloseType    --> reuse from contact-1.0.xsd
    * creDataType     --> reuse from contact-1.0.xsd
    * checkType       --> reuse from contact-1.0.xsd 
    * chkDataType     --> reuse from contact-1.0.xsd
[Linlin] Yes, this is a good suggestion. I'll consider revising the XSD.

- the XSD; the postalInfoType is almost the same as the contact one except the org field is missing. In chgPostalInfoType there is a org element. This is inconsistent. If the org element should be there as an optional field more types can be resumed.
[Linlin] Originally, we thought that a reseller name may be the same with a reseller org, so this element was deleted in the postalInfo. But for the consistency, this element could be an optional element.

- I've found the XSD refactoring the file itself. It removes over 100 lines from the XSD and makes it more understandable on how the object is constructed. I can provide it if you want. 
[Linlin] Thanks.

I did not go through all the text so there might be more comments, but if we decide to go for this reuse of elements in the psd there is much text to change. 


On 12 Oct 2015, at 12:27, Linlin Zhou <> wrote:

The reseller draft is updated to 02 version according to WG discussion. Any comments are welcome.
The name suggested by Marc of this draft is planning to be changed next version. The reseller status and postalinfo issues would like to be discussed in WG meeting. 

Linlin Zhou
From: internet-drafts
Date: 2015-10-12 11:12
Subject: I-D Action: draft-zhou-eppext-reseller-mapping-02.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-02.txt
Pages           : 31
Date            : 2015-10-11
   This document describes an Extensible Provisioning Protocol (EPP)
   mapping for provisioning and management of reseller object 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 resellers.
The IETF datatracker status page for this draft is:
There's also a htmlized version available at:
A diff from the previous version is available at:
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at
Internet-Drafts are also available by anonymous FTP at:
I-D-Announce mailing list
Internet-Draft directories:
EppExt mailing list