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

From: Rik Ribbers <[email-masked]>
Date: Fri, 6 Nov 2015 01:07:03 +0000

Hello Linlin,

Like stated in the WG I’ve collected my comments on the mapping draft.

Section 3.1 

- Add a clarification sentence "All reseller objects are identified by a server-unique identifier" (same as the reseller extension draft)

Section 3.3

- The Reseller state; I would have expected the epp statusses there. During the WG-meeting there were different opinions here. My preference would be to use epp statussen as a reseller in this draft is modelled as a fullblown EPP object. I'm curious to hear what other people think on this. If we decide not to go for app statuses I will request a subset of status values to match our implementation (I know at least one but have to check for others).

- The reseller draft states that a reseller can be referenced (optionally) by a name. In the XML structure there is no name at the highest level, only at add the postalInfo level. As a postal info can occur more then once in the xml there is no way to identify which name to use. This was addressed in the WG session and there are 2 possible solutions:
    1 remove the name in the reseller draft as it is optional. 
    2 add the name to the reseller object in this draft; The only thing to consider is do we need the name at the postalInfo level then.
I'd prefer option 1, but I can live with option 2

- the XSD; with all EPP schemas there is a schemaLocation attribute (see domain an contact RFCs) I don't see them in the XSDs here. Allthough it is an optional field I would put them there for consistency reasons.

- the XSD; I would strongly recommend reusing XML Type from other EPP objects if available. There are several Types in the XSD which are already available in the other existing XSD, why not reuse them. Escpecially when there is already a dependancy on the contact xsd in there. Below a list of type which are candidates for replacing. The list is probably longer.
    * contactAddrType --> reuse from domain-1.0.xsd 
    * contactType     --> reuse from domain-1.0.xsd (depends on contactAddrType)
    * postalInfoType  --> could be reused from contact-1.0.xsd depending on how the name referencing issue is resolved (see remark below)
    * addrType        --> reuse from contact-1.0.xsd
    * discloseType    --> reuse from contact-1.0.xsd
    * creDataType     --> reuse from contact-1.0.xsd
    * checkType       --> reuse from contact-1.0.xsd 
    * chkDataType     --> reuse from contact-1.0.xsd

- the XSD; the postalInfoType is almost the same as the contact one except the org field is missing. In chgPostalInfoType there is a org element. This is inconsistent. If the org element should be there as an optional field more types can be resumed.

- I've found the XSD refactoring the file itself. It removes over 100 lines from the XSD and makes it more understandable on how the object is constructed. I can provide it if you want. 

I did not go through all the text so there might be more comments, but if we decide to go for this reuse of elements in the psd there is much text to change. 

Gr,
Rik

> On 12 Oct 2015, at 12:27, Linlin Zhou <[email-masked]> wrote:
> 
> 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. The reseller status and postalinfo issues would like to be discussed in WG meeting. 
> 
> Linlin Zhou
>  
> From: internet-drafts <mailto:[email-masked]>
> Date: 2015-10-12 11:12
> To: [email-masked] <mailto:[email-masked]>
> Subject: I-D Action: draft-zhou-eppext-reseller-mapping-02.txt
>  
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  
>  
>         Title           : Extensible Provisioning Protocol (EPP) Reseller Mapping
>         Authors         : Linlin Zhou
>                           Ning Kong
>                           Chao Qi
>                           Xiaodong Lee
>                           James Gould
> Filename        : draft-zhou-eppext-reseller-mapping-02.txt
> Pages           : 31
> Date            : 2015-10-11
>  
> Abstract:
>    This document describes an Extensible Provisioning Protocol (EPP)
>    mapping for provisioning and management of reseller object 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 resellers.
>  
>  
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-zhou-eppext-reseller-mapping/ <https://datatracker.ietf.org/doc/draft-zhou-eppext-reseller-mapping/>
>  
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-zhou-eppext-reseller-mapping-02 <https://tools.ietf.org/html/draft-zhou-eppext-reseller-mapping-02>
>  
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-zhou-eppext-reseller-mapping-02 <https://www.ietf.org/rfcdiff?url2=draft-zhou-eppext-reseller-mapping-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 <http://tools.ietf.org/>.
>  
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/>
>  
> _______________________________________________
> I-D-Announce mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/i-d-announce <https://www.ietf.org/mailman/listinfo/i-d-announce>
> Internet-Draft directories: http://www.ietf.org/shadow.html <http://www.ietf.org/shadow.html>
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>_______________________________________________
> EppExt mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/eppext <https://www.ietf.org/mailman/listinfo/eppext>

---

From: Roger D Carney <[email-masked]>
Date: Thu, 19 Nov 2015 22:06:45 +0000

Good Afternoon,

If we are looking for this (and corresponding reseller) I-D to be used as the mechanism to solve the forthcoming Thin/Thick CL&D requirement for registries to display Reseller Name in the WHOIS output, we will need to make almost all of this data optional. As the forthcoming requirement is for the display of the reseller name only, many Registrars will only supply that one data element (and id).

Thanks
Roger

From: EppExt [mailto:[email-masked]] On Behalf Of Rik Ribbers
Sent: Thursday, November 05, 2015 7:07 PM
To: Linlin Zhou; Ning Kong <nkong@cnnic. cn>; [email-masked]
Subject: Re: [eppext] I-D Action: draft-zhou-eppext-reseller-mapping-02.txt

Hello Linlin,

Section 3.1

Section 3.3

Gr,
Rik

On 12 Oct 2015, at 12:27, Linlin Zhou <[email-masked]<mailto:[email-masked]>> wrote:

________________________________
Linlin Zhou

From: internet-drafts<mailto:[email-masked]>
Date: 2015-10-12 11:12
To: [email-masked]<mailto:[email-masked]>
Subject: I-D Action: draft-zhou-eppext-reseller-mapping-02.txt

Abstract:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-zhou-eppext-reseller-mapping/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-zhou-eppext-reseller-mapping-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-zhou-eppext-reseller-mapping-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<http://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]<mailto:[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
_______________________________________________
EppExt mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eppext

---

From: "Linlin Zhou" <[email-masked]>
Date: Fri, 20 Nov 2015 10:34:30 +0800

Hi Rik,
Thanks for your comments. Please see my feedback inline.

Linlin Zhou
 
From: Rik Ribbers
Date: 2015-11-06 09:07
To: Linlin Zhou; Ning Kong <[email-masked]>; [email-masked]
Subject: Re: [eppext] I-D Action: draft-zhou-eppext-reseller-mapping-02.txt
Hello Linlin,

Section 3.1 

- Add a clarification sentence "All reseller objects are identified by a server-unique identifier" (same as the reseller extension draft)
[Linlin] Ok. This should be added.

Section 3.3

- The Reseller state; I would have expected the epp statusses there. During the WG-meeting there were different opinions here. My preference would be to use epp statussen as a reseller in this draft is modelled as a fullblown EPP object. I'm curious to hear what other people think on this. If we decide not to go for app statuses I will request a subset of status values to match our implementation (I know at least one but have to check for others).
[Linlin] Yes, I would like also hear more about others' opinions, epp status, subset of epp status or some customized status? Could you provide your status examples?

[Linlin] I also think option 1 is a simple solution to this issue.

- the XSD; with all EPP schemas there is a schemaLocation attribute (see domain an contact RFCs) I don't see them in the XSDs here. Allthough it is an optional field I would put them there for consistency reasons.
[Linlin] Actually I didn't find the schemaLocation attribute in RFC5731 and 5733. Could you help give me some hint?

[Linlin] Yes, this is a good suggestion. I'll consider revising the XSD.

- the XSD; the postalInfoType is almost the same as the contact one except the org field is missing. In chgPostalInfoType there is a org element. This is inconsistent. If the org element should be there as an optional field more types can be resumed.
[Linlin] Originally, we thought that a reseller name may be the same with a reseller org, so this element was deleted in the postalInfo. But for the consistency, this element could be an optional element.

[Linlin] Thanks.

Gr,
Rik

Linlin Zhou
 
From: internet-drafts
Date: 2015-10-12 11:12
To: [email-masked]
Subject: I-D Action: draft-zhou-eppext-reseller-mapping-02.txt

 
Abstract:

 

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.

[email-masked]
[email-masked]

---

From: Rik Ribbers <[email-masked]>
Date: Fri, 20 Nov 2015 07:41:01 +0000

> [Linlin] Yes, I would like also hear more about others' opinions, epp status, subset of epp status or some customized status? Could you provide your status examples?

[rik] Yes I can:

linked; Reseller linked to at least one domain
ok; Normal (default) status     			       
pendingUpdate; Reseller <update> in progress

> [Linlin] Actually I didn't find the schemaLocation attribute in RFC5731 and 5733. Could you help give me some hint?

[rik] You are completely correct. This is an mistake by my own, I have some tooling in place where I added it myself to get the xml validation up and running….

Gr,
Rik

---

From: Patrick Mevzek <[email-masked]>
Date: Fri, 20 Nov 2015 11:38:11 +0200

Le vendredi 20 novembre 2015 à 07:41 +0000, Rik Ribbers a écrit :

> [rik] You are completely correct. This is an mistake by my own, I have
> some tooling in place where I added it myself to get the xml
> validation up and running….

It would maybe be interesting/into EPPEXT scope, to provide some
guidance to extensions' authors, both on the namespace to use (as there
is a lot of ways, from http://whatever to urn:ietf:whatever to
urn:X-whatever and so on), and if the schemaLocation attribute
should/must be included.

There is nothing (a little on namespaces but really nothing on
schemaLocation) in RFC3735 about that and a ton of new extensions have
been created since then.

Also in fact by re-reading this RFC now I come over this part, which
does not seem to me very well in line with the existence of the IANA
registry on EPP extensions:
Extensions need not be published as Internet-Draft or RFC documents
if they are intended for operation in a closed environment or are
otherwise intended for a limited audience. In such cases extensions
MAY be documented in a file and structural format that is appropriate
for the intended audience

-- 
Patrick Mevzek

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 20 Nov 2015 12:03:26 +0000

> -----Original Message-----
> From: EppExt [mailto:[email-masked]] On Behalf Of Patrick
> Mevzek
> Sent: Friday, November 20, 2015 4:38 AM
> To: [email-masked]
> Subject: [eppext] schemaLocation (was Re: I-D Action: draft-zhou-
> eppext-reseller-mapping-02.txt)

[snip]

> for the intended audience

That's actually completely consistent with 7451. All the registry needs is a reference to the local specification.

Scott