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

["Gould, James" <[e-mail]>]

My feedback to the feedback is below.



—


JG


[cid:[e-mail]]

James Gould
Distinguished Engineer
[e-mail]

703-948-3271
12061 Bluemont Way
Reston, VA 20190

VerisignInc.com<http://VerisignInc.com>

On May 18, 2015, at 12:00 AM, Linlin Zhou <[e-mail]<mailto:[e-mail]>> wrote:

Hi Patrick,
Thanks for your review. Please see my feedback below.

Regards,
Linlin

> -----原始邮件-----
> 发件人: "Patrick Mevzek" <[e-mail]<mailto:[e-mail]>>
> 发送时间: 2015-05-17 08:14:33 (星期日)
> 收件人: [e-mail]<mailto:[e-mail]>
> 抄送:
> 主题: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-00.txt
>
> Hello Linlin, Ning, Chao, Xiaodong, and James,
>
> Linlin Zhou <[e-mail]<mailto:[e-mail]>> 2015-05-04 10:28
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >
> >
> > Title : Registry Reseller Extension for the Extensible Provisioning Protocol (EPP)
> > Authors : Linlin Zhou
> > Ning Kong
> > Chao Qi
> > Xiaodong Lee
> > James Gould
> > Filename : draft-zhou-eppext-reseller-00.txt
> > Pages : 16
> > Date : 2015-05-04
>
> I'm implementing it in my opensource EPP client, and I have the
> following comments/questions:
>
> - the resName node is of type "string", without any lower limit of
> length, I believe it would make sense to mandate at least one
> character…
>
Agree. A minLength attibute will be added.


I would match the resellerext:resName element of draft-zhou-eppext-reseller with the reseller:name element of draft-zhou-eppext-reseller-mapping, which is of type contact:postalLineType.  Within draft-zhou-eppext-reseller  I would directly define the resName type in the schema in place of creating a dependency to the contact mapping.  For example:

…

      <element name="resName" type=“resellerext:resNameType"/>


...


  <simpleType name=“resNameType">
     <restriction base="normalizedString">
       <minLength value="1"/>
       <maxLength value="255"/>
     </restriction>
  </simpleType>



> - since create and update operations are extended for all 3 kind of
> core EPP objects (domain, host, contact), there should be some more
> explanations on what happens when a domain name is created with
> reseller X, where in-bailiwick hosts of this domain are created with
> reseller Y and contacts used for the domain were created with reseller
> Z. Does that make any sense? Does the registry want to permit this
> case?
>
I think this issue depends on registry policy. In many registries, this scenario is allowed.


Yes, this depends on registry policy, but in general the objects are independently managed (domain from client X can reference a host or contact from client Y).  Child hosts are typically only managed by the sponsoring client of the parent domain, but I would not attempt to try to define any policies around object relationships within the extension.


> - there should be some explanations on what happens for a domain name
> with a reseller that get transfered to another registrar (where
> obvisouly the given previous reseller would not exist). Will the
> reseller info be automatically removed after the transfer finishes?
>
If a domain is transfered to a new registrar, the registrar or reseller will do a domian update operation to update the corresponding reseller information.


I agree that some clarifying text would be helpful here.  Even though the reseller object is managed as a first class object via draft-zhou-eppext-reseller-mapping, the reseller is tightly coupled with the sponsoring client (registrar).  Change of the sponsoring client via a successful transfer (directly for an object like domain or indirectly for an object like host) should impact the reseller setting as well.  This could be added to section 4.2.4 "EPP <transfer> Command”, where “This extension does not add any elements to the EPP <transfer> command or <transfer> response described in the [RFC5730], but after a successful transfer of an object with an assigned reseller, the server SHOULD clear the assigned reseller value.”

We could update draft-zhou-eppext-reseller to be more object agnostic similar to the text in draft-gould-change-poll “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.


> - I'm not sure to understand completely the update case.
> In short, in my understanding, I would expect that there would be a
> sentence stating that "only one add, or rem or chg element is
> permitted", so that there are not mix of add/rem/chg, because in that
> later case it would be difficult to understand what happens.
> Also in that case there should be explanations on what happens when
> the registrar does an add where the domain already has a reseller (for
> me that should be rejected, because a registrar should do a chg in
> that case), and what happens for a del where the domain has no
> reseller (this could be handled as a noop), and what happens for a chg
> where there is no reseller for now (this should be rejected)
>
Yes, this should be "only one" element, I'll make it explicitely.
The three examples you mentioned should be rejected. Error codes defined in RFC5730 should be included in the response.


This could be simplified by just supporting a <resellerext:update> element that takes the <resellerext:resID> element along with the optional <resellerext:resName> element to set or replace the existing value and with the support for an empty <resellerext:update> element to clear or remove the reseller as in <resellerext:update xmlns:resellerext=“urn:ietf:params:xml:ns:resellerext-1.0”/>.  The semantics of add and remove really don’t apply if there is a one to one relationship between the provisioning object and the reseller.


> For the chg case, there should be a clear explanation on what happens
> if we have a resID+resName currently but the chg element contains only
> the resID… will the resName be removed automatically? This should be
> more specified, as it is similar to that postalAddress problem in core
> EPP.
Yes, it is similar to the postalAddress problem. I think this is also a registry policy issue. For example, many registries do not allow to updat ID only. You must update ID and at least a name.
I'd like to see more feedbacks from WG. If this problem indeed makes others confused, I'll try to add some text next version.

There actually may be little need for the <resellerext:resName> element for the extension to create and update in draft-zhou-eppext-reseller, since the <reseller:resID> references a <reseller:id> in draft-zhou-eppext-reseller-mapping.  The reseller object defined by the <resellerext:resID> should already exist, and the management of the name (along with other attributes) should be handled by draft-zhou-eppext-reseller-mapping.  The reseller name can be returned in the extension to the info response of draft-zhou-eppext-reseller as a convenience.

>
> --
> Patrick Mevzek
>
> _______________________________________________
> EppExt mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/eppext
_______________________________________________
EppExt mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eppext