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

"Linlin Zhou" <> Tue, 20 October 2015 05:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C93061A066C for <>; Mon, 19 Oct 2015 22:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Status: No, score=-2.61 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id znVAn_TRqpGZ for <>; Mon, 19 Oct 2015 22:54:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 305A41A0545 for <>; Mon, 19 Oct 2015 22:54:01 -0700 (PDT)
Received: from zll (unknown []) by (Coremail) with SMTP id AQAAf0CJkDjq1iVW2g7OBA--.9091S2; Tue, 20 Oct 2015 13:53:46 +0800 (CST)
Date: Tue, 20 Oct 2015 13:54:01 +0800
From: "Linlin Zhou" <>
To: "Rik Ribbers" <>, "" <>
References: <>, <C80127C588F8F2409E2B535AF968B768BA2A35B3@kambx2.SIDN.local>
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_NextPart407026318747_=----"
X-Coremail-Antispam: 1UD129KBjvJXoW3Jw1Dtr47GrW8uFy7Kw47CFg_yoWxCF1rpF W3WrWagr1kAay0y39avF18X3W0yryFyFWrGrs5Jryjva98GFy0qr4Fywn09FWUCr1Fv3W5 Zr42kwn0yr4UZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUdab7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40Eb7x2 x7xS6ryj6rWUMc02F40E57IF67AEF4xIwI1l5I8CrVAKz4kIr2xC04v26r1j6r4UMc02F4 0E42I26xC2a48xMc02F40Ex7xS67I2xxkvbII20VAFz48EcVAYj21lYx0E2Ix0cI8IcVAF wI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0x vY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xvF2IEb7IF0Fy26I8I3I1lc2xSY4AK 67AK6r4rMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrV AFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCI c40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267 AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWU JVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UMVCEFcxC0VAYjxAxZFUvcSsGvfC2Kf nxnUUI43ZEXa7IU59TmDUUUUU==
X-CM-SenderInfo: p2kr3zplqox0w6fq0xffof0/
Archived-At: <>
Subject: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-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: Tue, 20 Oct 2015 05:54:08 -0000

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


Linlin Zhou
From: Rik Ribbers
Date: 2015-10-19 23:17
To: 'Linlin Zhou';
Subject: RE: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-02.txt
Hello LinLin,
In preparation for Yokohama I'm catching up an all the drafts on the agenda. I've read the reseller extension draft and have some remarks:
- The abstract of an I-D should be able to stand alone outside the document without references. So I suggest to remove the reference to RFC5731. This remark is triggered by another remark from Scott during WG last call for keyrelay (see point 2 in )
[Linlin] Thanks. This will be revised.
- Section 1:
   A reseller mapping object defined in
   [ID.draft-zhou-eppext-reseller-mapping] SHOULD be created first.  The
   reseller information specified in this document SHOULD reference the
   existing reseller identifier and reseller name.
The I-D states only references to reseller identifier and not name. So the last part (and reseller name) can be removed. The name is optional so it cannot be used for referencing.
[Linlin] In this paragraph, I would like to explain that the <resellerext:id> should refer to <reseller:id> and the optional <resellerext:name> should refer to <reseller:name>. In my opinion, the optional name element should also be in compliance with the existing reseller object name.
- Section 3.1. All highlevel object like contact and host specify somethings about identifier being unique within the server (e.g. RFC 5732 section 2.1) I suggest to do the same here for Reseller Identifier. The same applies for the reseller mapping draft.
[Linlin] I guess you mean RFC5732 section 2.2. I'll add a sentence such as "All reseller objects are identified by a server-unique identifier" in two drafts.
- Section 3.2 Same here : specify that the name is optional, but added for readability. And maybe add some wording that it is there to comply with existing implementations? I don't know it the last one is actually true but this is what I've understood so far.
[Linlin] See the above explanation.
- Section 4.2.3 : For readability I suggest to move the last 2 sentence in front of the example. I overlooked them the first time I read the draft.
[Linlin] I think maybe the text layout caused the overlook problem. Almost all of the examples follow the last 2 sentences. To keep the consistency, I suggest leaving them there.
- XML Namespacing: I suggest to shorten the namespace prefix to "re" and the URN to resellerExtension. Although this is a matter of taste I don't like the resellerext naming as the ext postfix can be serveral things: extension, external of something else. Given the context it is quite obvious what it is though.
[Linlin] This is a personal naming habit. We could discuss it in private:)
- Section 4.2.5 The section describing how many add and remove elements are allowed is not directly clear to me. In our own reseller implementation we have the possibility to use 2 elements (an add and remove element) for changing the reseller. I think this is written there, but I'm not quite sure. And is there a typo where there are 2 rem elements? I guess one of them should be a chg? I have a suggestion for the wording
Current text
   At least one and only one <resellerext:add>, <resellerext:rem> or
   <resellerext:rem> element MUST be provided.  The <resellerext:add>,
   <resellerext:rem> and <resellerext:rem> elements contain the
   following child element:
My suggestion would be this (this makes the draft more compatible with our implementation):
   At least one of <resellerext:add>, <resellerext:rem> or <resellerext:chg> element MUST be provided. Only one <resellerext:chg> element MUST be allowed. If a <resellerext:chg> element is provided a <resellerext:add>, <resellerext:rem> element MUST NOT be allowed. Only one <resellerext:add> and <resellerext:rem> MUST be allowed. A <resellerext:add> and <resellerext:rem> MAY be combined into one <resellerext:update> element. 
[Linlin] Yes, there's an extra rem, this should be chg. The suggested text looks good to me. I'll update it.
-Section 5 formal syntax There is a typo in the schema : resellerr
<schema targetNamespace="urn:ietf:params:xml:ns:resellerext-1.0"
[Linlin] Yes. This should be xmlns:resellerext="urn:ietf:params:xml:ns:resellerext-1.0". Thank you.
Kind regards,
From: EppExt [] On Behalf Of Linlin Zhou
Sent: maandag 12 oktober 2015 5:27
Subject: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-02.txt
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.

Linlin Zhou
From: internet-drafts
Date: 2015-10-12 11:16
Subject: I-D Action: draft-zhou-eppext-reseller-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
        Title           : Reseller Extension for the Extensible Provisioning Protocol (EPP)
        Authors         : Linlin Zhou
                          Ning Kong
                          Chao Qi
                          Xiaodong Lee
                          James Gould
Filename        : draft-zhou-eppext-reseller-02.txt
Pages           : 17
Date            : 2015-10-11
   This mapping, an extension to EPP object mappings like the EPP domain
   name mapping [RFC5731], to support assigning a reseller to any
   existing object (domain, host, contact) as well as any future
   objects.  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: