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

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 4 May 2015 16:29:34 +0800

Dear all,

CNNIC proposed a EPP reseller extension on the last ROW meeting. Based on this proposal, two drafts were submitted. 

draft-zhou-eppext-reseller is about the reseller extensions of EPP for domain names, hosts and contacts. draft-zhou-eppext-reseller-mapping is a document that describes the EPP reseller object mapping.

Any comments are welcome.

Regards,

Linlin Zhou
 
From: internet-drafts
Date: 2015-05-04 16:04
To: [email-masked]
Subject: I-D Action: draft-zhou-eppext-reseller-00.txt
 
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
 
Abstract:
   This document describes an Extensible Provisioning Protocol (EPP) for
   provisioning and management of registry reseller extensions for
   domain names, hosts and contacts stored in a shared central
   repository.  Specified in Extensible Markup Language (XML), this
   extended mapping is applied to provide additional features required
   for the provisioning of registry 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-00

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
[email-masked]
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

---

From: Marc Groeneweg <[email-masked]>
Date: Mon, 4 May 2015 11:52:35 +0000

Dear Linlin Zhou,

I want to review your reseller drafts on Wednesday. Please not that SIDN also wanted to release their EPP Reseller drafts, but I’ll check our reseller mapping with your suggestions. So ‘till Wednesday.

Regards,
Marc Groeneweg
SIDN

From: EppExt [mailto:[email-masked]] On Behalf Of Linlin Zhou
Sent: maandag 4 mei 2015 10:30
To: [email-masked]
Subject: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-00.txt

Dear all,

Regards,
________________________________
Linlin Zhou

From: internet-drafts<mailto:[email-masked]>
Date: 2015-05-04 16:04
To: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-zhou-eppext-reseller-00.txt

Abstract:

[email-masked]<mailto:[email-masked]>

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 5 May 2015 16:29:13 +0800

Thanks for your attention. Any comments or suggestions are appreciated and welcome.

Regards,

Linlin Zhou
 
From: Marc Groeneweg
Date: 2015-05-04 19:52
To: 'Linlin Zhou'; [email-masked]
Subject: RE: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-00.txt
Dear Linlin Zhou,

Regards,
Marc Groeneweg
SIDN

Dear all,

 
 
Regards,

Linlin Zhou
 
From: internet-drafts
Date: 2015-05-04 16:04

 
Abstract:

---

From: Patrick Mevzek <[email-masked]>
Date: Sun, 17 May 2015 02:14:33 +0200

Hello Linlin, Ning, Chao, Xiaodong, and James,

Linlin Zhou <[email-masked]> 2015-05-04 10:28
> Filename        : draft-zhou-eppext-reseller-00.txt
 
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…

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

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

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

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.

-- 
Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Sun, 17 May 2015 03:31:35 +0200

Patrick Mevzek <[email-masked]> 2015-05-17 02:15
> following comments/questions:
 
Also:

- the XML example in the domain:info response is invalid:
<domain:infData xmlns="urn:ietf:params:xml:ns:domain-1.0">
should be
<domain:infData xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">

-- 
Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Sun, 17 May 2015 03:35:07 +0200

> later case it would be difficult to understand what happens.

The comments in the XML schema are strange:
<!--
Child elements of <reseller:update> command
Cannot be added or removed, only change is allowed
At least one element should be present
-->

-- 
Patrick Mevzek

---

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 18 May 2015 12:00:04 +0800

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

Regards,
Linlin

> -----原始邮件----- 
> 发件人: "Patrick Mevzek" <[email-masked]> 
> 发送时间: 2015-05-17 08:14:33 (星期日) 
> 收件人: [email-masked] 
> 抄送: 
> 主题: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-00.txt 
> 
Agree. A minLength attibute will be added.

> Z. Does that make any sense? Does the registry want to permit this 
I think this issue depends on registry policy. In many registries, this scenario is allowed.

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

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

> more specified, as it is similar to that postalAddress problem in core 
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.
> EppExt mailing list 
> [email-masked] 
> https://www.ietf.org/mailman/listinfo/eppext

---

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 18 May 2015 12:00:24 +0800

Thanks. I'll delete the "stange" comments.

Regards,

Linlin Zhou
 
From: Patrick Mevzek
Date: 2015-05-17 09:35
To: eppext
Subject: Re: [eppext] Fw: I-D Action: draft-zhou-eppext-reseller-00.txt
Patrick Mevzek <[email-masked]> 2015-05-17 02:15

-- 
Patrick Mevzek

---

From: "Linlin Zhou" <[email-masked]>
Date: Mon, 18 May 2015 12:00:36 +0800

Thanls for finding the typo.

Regards,

Linlin Zhou
 
From: Patrick Mevzek
Date: 2015-05-17 09:31
To: eppext
Also:

-- 
Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Mon, 18 May 2015 13:07:33 +0000

My feedback to the feedback is below.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

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

Hi Patrick,

Regards,
Linlin

> -----原始邮件-----
> 发件人: "Patrick Mevzek" <[email-masked]<mailto:[email-masked]>>
> 收件人: [email-masked]<mailto:[email-masked]>
> 抄送:
> Linlin Zhou <[email-masked]<mailto:[email-masked]>> 2015-05-04 10:28

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>

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.

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.

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.

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.

> [email-masked]<mailto:[email-masked]>
_______________________________________________
EppExt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eppext

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 18 May 2015 16:15:51 +0200

Linlin Zhou <[email-masked]> 2015-05-18 05:59
> 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.

Not necessarily possible, if the new registrar does not use at all the
resellerext EPP extension… and I doubt that a registry could mandate
all registrars to use it.
And even if he uses the extension, what mandates him to update the 
domain? Technically, nothing. If the reseller info is displayed 
somewhere (whois, escrow, etc…), then a wrong information would be 
shown.

This is the same problem as a transfer with secDNS information.

So it will probably be a registry policy, but we may have some 
scenarios where the reseller info will be kept through the transfer, 
and other scenarios where it will be wiped out (and if the new 
registrar wants to specify its own reseller he will do a domain:update
afterwards).
But maybe the draft should have a sentence about that.

2 other points while I'm at it and implementing your other draft:
- I will post comments later on your other drafts
- I believe there should be somewhere an explanation on how your two 
  drafts articulate between themselves. My understanding is that 
registrars will create reseller objets with the reseller mapping I-D,
and then create domains with the resellerID for the reseller object
they created previsouly. If that is not what is intended, some
clarifications should be added somewhere.

-- 
Patrick Mevzek

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 19 May 2015 10:30:45 +0800

Hi James,

Thanks for your feedback.

> <restriction base="normalizedString"> 
Yes, this is the revised resName xml schema.

...
> 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 exi…
I agree with you that this method is more simplified. I'll consider updating the text.

Regards,
Linlin

---

From: "Linlin Zhou" <[email-masked]>
Date: Tue, 19 May 2015 11:53:36 +0800

Hi Patrick,

> 发送时间: 2015-05-18 22:15:51 (星期一) 
> 收件人: [email-masked] 
> 抄送: 
I understand your consideration. I agree that some text should be added to clarify this problem. What do you think about James' suggested text? 
"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."

> - I will post comments later on your other drafts 
Comments are welcome.

> clarifications should be added somewhere. 
Yes, you are right. This is what I am thinking about. There should be some text to describe the relationship between the two drafts. I intend to add a sentence in the intrduction section, such as "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." 
Then indicate the specified elements defined in draft-zhou-eppext-reseller-mapping in section 3.1 and 3.2. For example:

3.1. Reseller Identifier 

Reseller identifier provides the ID of the reseller of a sponsoring 
registrar. Its corresponding element is <resellerext:resID> defined 
in this document. It refers to the <reseller:id> element defined in [ID.draft-zhou-eppext-reseller-mapping].

3.2. Reseller Name 

Reseller name provides the name of the reseller of a sponsoring 
registrar. Its corresponding element is <resellerext:resName> 
defined in this document. It refers to the <reseller:name> element defined in [ID.draft-zhou-eppext-reseller-mapping].

Regards,
Linlin