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

Rik Ribbers <rik.ribbers@sidn.nl> Tue, 20 October 2015 07:35 UTC

Return-Path: <rik.ribbers@sidn.nl>
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 951081AD06E for <eppext@ietfa.amsl.com>; Tue, 20 Oct 2015 00:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.295
X-Spam-Level:
X-Spam-Status: No, score=0.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 dw7PnAZQJjT6 for <eppext@ietfa.amsl.com>; Tue, 20 Oct 2015 00:35:44 -0700 (PDT)
Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680011AD060 for <eppext@ietf.org>; Tue, 20 Oct 2015 00:35:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:x-originating-ip:content-type:mime-version; bh=opLg1Kcr8rwBq52Dafpdzk4lG0lBMVA8yfnO4DWQdPs=; b=h1M/fYjGQeYUK/Fyb0vtNrqwW1XTz57R14ZQo1/NMGAlAUq9+wGp3pSZw6bZDZRqODU0a0a/6ESa8HkMEQxpLbG2RQfKhb6B/TG33NZTVvOqMd4qNqntRaKbVEO3YtjYjmCajuxF63ZRqVy7Dy62/D1a+28VdTVmgIPbfS0uj9OQYd1swYTnixeIstWTGcyCFX1wbTjwZ7efBdBm1F/2vyPZvS3UE6zkfqQXDoWD8YQ37PL2EmKyeot44cA959vj4ybCpmOf3xN8gZNROHXvfqkbuizYCZ97uy8UB2Sse4kbDZcyP/BZdIlqGoikBH/2UwMNhLSyyphTXjr6yUe8dA==
Received: from ka-mbx03.SIDN.local ([192.168.2.179]) by arn2-kamx.sidn.nl with ESMTP id t9K7ZaHN020774-t9K7ZaHP020774 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Tue, 20 Oct 2015 09:35:36 +0200
Received: from KAHUBCASN02.SIDN.local (192.168.2.76) by ka-mbx03.SIDN.local (192.168.2.179) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 20 Oct 2015 09:35:53 +0200
Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn02 ([192.168.2.74]) with mapi id 14.03.0224.002; Tue, 20 Oct 2015 09:35:36 +0200
From: Rik Ribbers <rik.ribbers@sidn.nl>
To: 'Linlin Zhou' <zhoulinlin@cnnic.cn>, "eppext@ietf.org" <eppext@ietf.org>
Thread-Topic: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-02.txt
Thread-Index: AQHRBJ31T7rmdBeMGEmu7MNxJeQn7p5y916AgAD274+AABtHEA==
Date: Tue, 20 Oct 2015 07:35:35 +0000
Message-ID: <C80127C588F8F2409E2B535AF968B768BA2B4CF5@kambx2.SIDN.local>
References: <2015101211272745137723@cnnic.cn>, <C80127C588F8F2409E2B535AF968B768BA2A35B3@kambx2.SIDN.local> <2015102013540118607381@cnnic.cn>
In-Reply-To: <2015102013540118607381@cnnic.cn>
Accept-Language: nl-NL, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.2.171]
Content-Type: multipart/alternative; boundary="_000_C80127C588F8F2409E2B535AF968B768BA2B4CF5kambx2SIDNlocal_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/iL1wACUKW8-yQKqywp2xaFlSCjI>
Subject: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-02.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, 20 Oct 2015 07:35:47 -0000

Hello Linlin,

Some comments below.

Gr
Rik
From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Linlin Zhou
Sent: dinsdag 20 oktober 2015 7:54
To: Rik Ribbers; eppext@ietf.org
Subject: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-02.txt

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

Regards,
________________________________
Linlin Zhou

From: Rik Ribbers<mailto:rik.ribbers@sidn.nl>
Date: 2015-10-19 23:17
To: 'Linlin Zhou'<mailto:zhoulinlin@cnnic.cn>; eppext@ietf.org<mailto:eppext@ietf.org>
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 https://www.ietf.org/mail-archive/web/eppext/current/msg00615.html )
[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.
 [Rik] Ok

- 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.
 [Rik] Exactly what I would expect

- 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.
[Rik] ok

- 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:)
[Rik] lets do that ;-)

- 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.
[Rik] ok

-Section 5 formal syntax There is a typo in the schema : resellerr

<schema targetNamespace="urn:ietf:params:xml:ns:resellerext-1.0"
        xmlns:resellerr="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,
Rik

From: EppExt [mailto:eppext-bounces@ietf.org] On Behalf Of Linlin Zhou
Sent: maandag 12 oktober 2015 5:27
To: eppext@ietf.org<mailto:eppext@ietf.org>
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<mailto:internet-drafts@ietf.org>
Date: 2015-10-12 11:16
To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org>
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

Abstract:
   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:
https://datatracker.ietf.org/doc/draft-zhou-eppext-reseller/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-zhou-eppext-reseller-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-zhou-eppext-reseller-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org<mailto:I-D-Announce@ietf.org>
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt