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

From: Marc Groeneweg <[email-masked]>
Date: Mon, 24 Aug 2015 12:57:16 +0000

Dear Linlin,

Herewith, as promised, my feedback on the draft proposal on the reseller extension:

General: why is this draft called draft-zhou-eppext-reseller instead of draft-zhou-eppext-reseller-ext? As it is the description of the extensions for reseller to other objects?

What is the reason you reference to [RFC5732] and [RFC5733], as the extension only extends the domain object [RFC5731]?

In general, shouldn’t refer to the reseller elements as reseller ext elements, as it describes the extensions to existing elements with reseller information?
I.e. the extension to the <info> command being a child <resellerExt:infData> instead of <reseller:infData>? This seems more obvious to me. Oh wait a moment, in your example you do call it reseller ext:inflate. The tekst is not in line with the example.

Why do you have an OPTIONAL <resellerext:name> element? Isn’t the name of a reseller part of the reseller object? And when one uses this element, does it refer to the parent reseller?

What is the purpose to he following statement?
"<info> response for the unauthorized client has not been changed, see [RFC5731], [RFC5732] and [RFC5733]for detail.”

In section 4.2.1. EPP <create> command you don’t reference to the OPTIONAL <resellerext:name> element.
Again, I don’t understand the references to the host and contact objects, since they are not extended in any way.

Section 4.2.5. EPP <update> command
I understand the need for the add and rem elements. With this one can add and remove references to reseller objects to the domain object.
I don’t understand the restriction for having only one add, rem or chg element. This prohibits the construction to change the reseller from A to B for given domain object. See following example from within .nl:

   C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
   C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"
   C:     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   C:  <command>
   C:    <update>
   C:      <domain:update
   C:       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
   C:        <domain:name>example.com</domain:name>
   C:      </domain:update>
   C:    </update>
   C:    <extension>
   C:      <resellerExt:update
   C:       xmlns:resellerExt="urn:ietf:params:xml:ns:sidn-ext-epp-reseller-1.0">
   C:        <resellerExt:rem>
   C:          <resellerExt:id>rs1234</resellerExt:id>
   C:        </resellerExt:rem>
   C:        <resellerExt:add>
   C:          <resellerExt:id>rs5678</resellerExt:id>
   C:        </resellerExt:add>
   C:      </resellerExt:update>
   C:    </extension>
   C:    <clTRID>ABC-12345</clTRID>
   C:  </command>
   C:</epp>

I guess the chg element is needed for changing the resellerext:name element? There is no mention to this.

Best regards,
Marc Groeneweg

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 25 Aug 2015 16:57:50 +0800

Dear Marc,
Thanks for your review. Please see my reply inline with the beginning of [Linlin].

Regards,

Linlin Zhou
 
From: Marc Groeneweg
Date: 2015-08-24 20:57
To: Linlin Zhou; [email-masked]
Subject: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-01.txt
Dear Linlin,

General: why is this draft called draft-zhou-eppext-reseller instead of draft-zhou-eppext-reseller-ext? As it is the description of the extensions for reseller to other objects?
    [Linlin] Ok. I think this is a good suggestion.

What is the reason you reference to [RFC5732] and [RFC5733], as the extension only extends the domain object [RFC5731]?
    [Linlin] This document does not only specify the reseller extension of domian object, but also host and contact objects. So [RFC5732] and [RFC5733] are in the reference section.

In general, shouldn’t refer to the reseller elements as reseller ext elements, as it describes the extensions to existing elements with reseller information?
I.e. the extension to the <info> command being a child <resellerExt:infData> instead of <reseller:infData>? This seems more obvious to me. Oh wait a moment, in your example you do call it reseller ext:inflate. The tekst is not in line with the example.
    [Linlin] Thanks. The name of the xml schema changed once. So there are three typos in section 4.1.2 and section 5. These wil be updated next version.

Why do you have an OPTIONAL <resellerext:name> element? Isn’t the name of a reseller part of the reseller object? And when one uses this element, does it refer to the parent reseller?
    [Linlin] Some suggestions metioned that the reseller id is sufficient, no need to add the name. To reach a compromise, the element is set optional. It refers to the object reseller not parent reseller.

What is the purpose to he following statement?
"<info> response for the unauthorized client has not been changed, see [RFC5731], [RFC5732] and [RFC5733]for detail.”
    [Linlin] In RFC5731, it defines authorized and unauthorized <info> responses. The reseller extension will not have effect on unauthorized <info> resoponse, so these text are added here to clarify.
In section 4.2.1. EPP <create> command you don’t reference to the OPTIONAL <resellerext:name> element. 
    [Linlin] 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.' So the <create> command will not create name element.

Again, I don’t understand the references to the host and contact objects, since they are not extended in any way.
    [Linlin] The domain extension examples provided in this document are used for illustation purpose. Host and contact object could be extended in the same way with the domain object. Otherwise, the document will be too prolix.

I guess the chg element is needed for changing the resellerext:name element? There is no mention to this.
    [Linlin] This is a review feedback from Patrik to avoid the mixture of add/rem/chg. See http://www.ietf.org/mail-archive/web/eppext/current/msg00510.html.