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

Rik Ribbers <rik.ribbers@sidn.nl> Mon, 19 October 2015 15:18 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 8DD221A9143 for <eppext@ietfa.amsl.com>; Mon, 19 Oct 2015 08:18:02 -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 bBXAJLB_Eg4b for <eppext@ietfa.amsl.com>; Mon, 19 Oct 2015 08:17:59 -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 96E5F1A911E for <eppext@ietf.org>; Mon, 19 Oct 2015 08:17:53 -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=TmM1sejpNHwxaPWvDv9iFgxqLC87XU/cdUwRQcvEqd4=; b=nORQizdx3TrJ/NkY1A4DAfkRsKaoDPPIpElOxKKbGUy3T0K9Hs0z6+N2ytbnsOvu6vrCcNNjPjE2WCEh1ezcxdUIrwOCK2frnfz9MbhEfs9yGw+nl4XTtwfw2COQZTUH+EjDxETgytIEHRkAi0FQMZclrxCTu6oFKbVHfdaZDOsCOQHdQCdadT6bXRDSv2RMemwvPwuxgvOFxVW9KYUfzgNHDO87jCesbLHe8M2iXdPMlCy6ikQmnDh1RFOZ6DOlSl+EdhxKIQvDrjb25CzLAysp8s9h3LbIqpV/WlSpPmQnVZqn4doCDtpP22uMfCwxDD96W/U7MeOQnfJcKUtbrQ==
Received: from ka-mbx02.SIDN.local ([192.168.2.178]) by arn2-kamx.sidn.nl with ESMTP id t9JFHidW030316-t9JFHidY030316 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL); Mon, 19 Oct 2015 17:17:44 +0200
Received: from KAHUBCASN02.SIDN.local (192.168.2.76) by ka-mbx02.SIDN.local (192.168.2.178) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 19 Oct 2015 17:17:44 +0200
Received: from KAMBX2.SIDN.local ([fe80::b1fd:88d9:e136:9655]) by kahubcasn02 ([192.168.2.74]) with mapi id 14.03.0224.002; Mon, 19 Oct 2015 17:17:44 +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: AQHRBJ31T7rmdBeMGEmu7MNxJeQn7p5y916A
Date: Mon, 19 Oct 2015 15:17:43 +0000
Message-ID: <C80127C588F8F2409E2B535AF968B768BA2A35B3@kambx2.SIDN.local>
References: <2015101211272745137723@cnnic.cn>
In-Reply-To: <2015101211272745137723@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_C80127C588F8F2409E2B535AF968B768BA2A35B3kambx2SIDNlocal_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/eppext/FuXRGr2Z_r0JtUOYAKI1bxVdYx0>
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: Mon, 19 Oct 2015 15:18:02 -0000

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 )

- 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.

- 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.

- 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.

- 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.

- 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.

- 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.


-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"


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
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