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

[Roger D Carney <[e-mail]>]

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:[e-mail]] On Behalf Of Rik Ribbers
Sent: Thursday, November 05, 2015 7:07 PM
To: Linlin Zhou; Ning Kong <nkong@cnnic. cn>; [e-mail]
Subject: Re: [eppext] I-D Action: draft-zhou-eppext-reseller-mapping-02.txt

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 <[e-mail]<mailto:[e-mail]>> 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:[e-mail]>
Date: 2015-10-12 11:12
To: [e-mail]<mailto:[e-mail]>
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/

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
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/eppext