Return-Path: 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 ; 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 ; 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 ; 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 To: "'Linlin Zhou'" , "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: References: <2015101211272745137723@cnnic.cn>, <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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2015 07:35:47 -0000 --_000_C80127C588F8F2409E2B535AF968B768BA2B4CF5kambx2SIDNlocal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 Date: 2015-10-19 23:17 To: 'Linlin Zhou'; 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 ke= yrelay (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 ca= nnot be used for referencing. [Linlin] In this paragraph, I would like to explain that the should refer to and the optional should= refer to . 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 something= s 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 exi= sting implementations? I don't know it the last one is actually true but th= is 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 th= e 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: extensio= n, external of something else. Given the context it is quite obvious what i= t 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 cha= nging 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 sho= uld be a chg? I have a suggestion for the wording Current text At least one and only one , or element MUST be provided. The , and elements contain the following child element: My suggestion would be this (this makes the draft more compatible with our = implementation): At least one of , or element MUST be provided. Only one element MUST be allo= wed. If a element is provided a , element MUST NOT be allowed. Only one and MUST be allowed. A and M= AY be combined into one 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 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 ver= sion. ________________________________ Linlin Zhou From: internet-drafts Date: 2015-10-12 11:16 To: 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 director= ies. Title : Reseller Extension for the Extensible Provisionin= g 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=3Ddraft-zhou-eppext-reseller-02 Please note that it may take a couple of minutes from the time of submissio= n 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 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 --_000_C80127C588F8F2409E2B535AF968B768BA2B4CF5kambx2SIDNlocal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Linl= in,

 = ;

Some comme= nts 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 se= e my feedback inline.

 

Regards,

Linlin Zhou

 

From: Rik Ribbers

Date: 2015-10-19 23:17<= /o:p>

Subject: RE: [eppext] Fw: I-D Act= ion: draft-zhou-eppext-reseller-02.txt

Hello LinL= in,

 

In prepara= tion for Yokohama I'm catching up an all the drafts on the agenda. I've rea= d the reseller extension draft and have some remarks:

 

- The abst= ract of an I-D should be able to stand alone outside the document without r= eferences. 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:

 

 &nbs= p; A reseller mapping object defined in<= o:p>

 &nbs= p; [ID.draft-zhou-eppext-reseller-mapping] SHOULD be created first.  T= he

 &nbs= p; reseller information specified in this document SHOULD reference the

 &nbs= p; existing reseller identifier and reseller name.

 

The I-D st= ates 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 &= lt;reseller:name>. In my opinion, the optional name element should also be in compliance with the existing re= seller object name.

 [Rik] Ok

 <= /p>

- Section = 3.1. All highlevel object like contact and host specify somethings about id= entifier being unique within the server (e.g. RFC 5732 section 2.1) I suggest to do the same here for Reseller Identifier. The same appli= es for the reseller mapping draft.<= /o:p>

[Linlin] I guess you mean RFC= 5732 section 2.2. I'll add a sentence such as "All reseller objects ar= e identified by a server-unique identifier" in two drafts.

 [Rik] Exactly what I would exp= ect

 = ;

- Section = 3.2 Same here : specify that the name is optional, but added for readabilit= y. 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 bu= t this is what I've understood so far.

[Linlin] See the above explan= ation.

 

- Section = 4.2.3 : For readability I suggest to move the last 2 sentence in front of t= he 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 Name= spacing: I suggest to shorten the namespace prefix to "re" and th= e 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: ext= ension, external of something else. Given the context it is quite obvious w= hat it is though.

[Linlin] Thi= s 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 i= s 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 sur= e. 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 te= xt

 &nbs= p;

 &nbs= p; At least one and only one <resellerext:add>, <resellerext:= rem> or

 &nbs= p; <resellerext:rem> element MUST be provided.  The <reseller= ext:add>,

 &nbs= p; <resellerext:rem> and <resellerext:rem> elements contain the=

 &nbs= p; following child element:

 

My suggest= ion would be this (this makes the draft more compatible with our implementa= tion):

 

 &nbs= p; At least one of <resellerext:add>, <resellerext:rem> or <= resellerext:chg> element MUST be provided. Only one <resellerext:chg&= gt; element MUST be allowed. If a <resellerext:chg> element is provided a <reselle= rext: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 extr= a rem, this should be chg. The suggested text looks good to me. I'll update= it.

[Rik] ok

 &nbs= p; 

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

 

<schema= targetNamespace=3D"urn:ietf:params:xml:ns:resellerext-1.0"

 &nbs= p;      xmlns:resellerr=3D"urn:ietf:params:x= ml:ns:resellerext-1.0"

[Linlin] Yes. This should be xmlns:rese= llerext=3D"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
Subject: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-02.txt<= /span>

 

The reseller draft is updated to 02= version according to WG discussion. Any comments are welcome. =

The name sugg= ested by Marc of this draft is planning to be changed next versio= n.

 

Linlin Zhou

 

Date: 2015= -10-12 11:16

Subject: I= -D Action: draft-zhou-eppext-reseller-02.txt

 

A New Internet-Draft is available f= rom the on-line Internet-Drafts directories.

 

 

      = ;  Title           := Reseller Extension for the Extensible Provisioning Protocol (EPP)

      = ;  Authors         : Linlin Zh= ou

      = ;            &n= bsp;       Ning Kong

      = ;            &n= bsp;       Chao Qi

      = ;            &n= bsp;       Xiaodong Lee

      = ;            &n= bsp;       James Gould

Filename    &nb= sp;   : draft-zhou-eppext-reseller-02.txt

Pages     =       : 17=

Date     &= nbsp;      : 2015-10-11

 

Abstract:

   This mapping, an exten= sion to EPP object mappings like the EPP domain

   name mapping [RFC5731]= , to support assigning a reseller to any=

   existing object (domai= n, host, contact) as well as any future<= o:p>

   objects.  Specifi= ed in Extensible Markup Language (XML), this

   extended mapping is ap= plied to provide additional features required

   for the provisioning o= f resellers.

 

 

The IETF datatracker status page fo= r this draft is:

 

There's also a htmlized version ava= ilable at:

 

A diff from the previous version is= available at:

 

 

Please note that it may take a coup= le 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:

 

___________________________________= ____________

I-D-Announce mailing list

Internet-Draft directories: http://www.ietf.org/shadow.html=

--_000_C80127C588F8F2409E2B535AF968B768BA2B4CF5kambx2SIDNlocal_--