Subject: Re: [regext] I-D Action: draft-ietf-regext-reseller-ext-01.txt

From: "Gould, James" <[email-masked]>
Date: Mon, 9 Jan 2017 19:05:10 +0000

Antoin,

Thank you for reviewing the drafts in detail.  I’ve responded to some of the items below prefixed with “JG-“.

Thanks,

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

From: regext <[email-masked]> on behalf of Antoin Verschuren <[email-masked]>
Date: Sunday, January 8, 2017 at 1:55 PM
To: Linlin Zhou <[email-masked]>
Cc: regext <[email-masked]>
Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-reseller-ext-01.txt

Hi Linlin and others,

I’ve taken the holiday season to make a more extensive review of the reseller drafts.
While we are still waiting on the suggestion and discussion of the reseller object itself, I already have some remarks/questions in advance:

First:
-I keep having issues identifying which document describes what when just looking at the name or title of the documents.
As far as I understand it:

Name: draft-ietf-regext-reseller-01
Title: Extensible Provisioning Protocol (EPP) Reseller Mapping
Describes the definition of the reseller object in EPP

and

Name: draft-ietf-regext-reseller-ext-01
Title: Reseller Extension for the Extensible Provisioning Protocol (EPP)
Describes how to map other objects to a reseller, how to include a reseller in a domain object etc.

Am I correct in this?

JG-Yes, that is correct the reseller mapping defines a reseller object with a unique identifier, and the extension extends other object mappings (e.g. domain, host, contact) to link to the reseller object based on the unique identifier.

This is confusing.
I keep having to forward to paragraph 4 before I understand which document I’m reading.
I suggest we take another good look at the names, titles and abstract text to make this more clear.
Suggestions (still a bit depending on the outcome of the object discussion):

Name: draft-ietf-regext-reseller
Title: Reseller Object for the Extensible Provisioning Protocol (EPP)
Describes the definition of the reseller object in EPP

JG-The existing title “Extensible Provisioning Protocol (EPP) Reseller Mapping” follows the model set by the EPP Object RFC’s, as in EPP Domain Name Mapping (RFC 5731), EPP Host Mapping (RFC), and EPP Contact Mapping (RFC 5733) for Object-level Extensions as defined in RFC 3735.  In this sense, Mapping represents “Object”, so EPP Domain Name Mapping is EPP Domain Name “Object” or EPP Reseller Mapping is EPP Reseller “Object”.  It would be best to leave the object mapping draft title as is to stay consistent with the RFC’s.

Name: draft-ietf-regext-reseller-mapping
Title: Mapping to a Reseller Object in the Extensible Provisioning Protocol (EPP)
Describes how to link other objects to a reseller, how to include a reseller in a domain object etc.

JG-The titles for Command-Response Extensions in RFC 3735 has not been as consist.  For example, RFC 3915 is a Command-Response Extension with the name “Domain Registry Grace Period Mapping for the Extensible Provisioning Protocol (EPP)” and RFC 5910 is a Command-Response Extension with the name “Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)”.  I believe it would be best to match the title convention of RFC 5910 for the Reseller Command-Response Extension as in “Reseller Extensions Mapping for the Extensible Provisioning Protocol (EPP)”.  The term “Mapping” by itself could represent an Object-level Extension and the term Extensions Mapping could represent a Command-Response Extension.  I recommend to use the convention “Protocol Extensions Mapping” for a Protocol-level Extension.

Both of the abstracts need to be rewritten as I believe they are mixed up.

JG-I believe to help with the mix up, the last sentence of the draft-ietf-regext-reseller-ext abstract can be modified to better reflect the purpose of the reseller command-response extension.  Since the extension is not associated with the provisioning of resellers but is associated with the provisioning of the relationship of objects to resellers, the last sentence could read “Specified in Extensible Markup Language (XML), this extension mapping is applied to relate objects to resellers to support reseller-level features like display, policy, and reporting.

-I also have an issue with the introductions of both drafts.
They don’t clearly describe what a reseller is, don’t follow previous definitions, and in one document it is described differently that in the other.
For one, I would like the word „ICANN accredited” removed. Resellers are not specific ICANN.
My suggested text for the first paragraph in the introduction of both documents:

"A registrar is an an entity that provides front-end domain name registration services to registrants, providing a public interface to registry services [RFC 3375].
A registrar has a contractual relationship with a registry and represents the sponsoring client to the server in [RFC5730].
While registrars are responsible for the registrants administrative registration data with a registry, they don't always have a direct relationship with the registrant.
Registrars often sell their administrative registration services through a network of resellers.
Resellers may or may not provide additional services to a registrant, like in-house or outsourced DNS operation or hosting services in one stop shop packages.
While registrants are bound to the rules and regulations of the registry and registrar through the resellers, they often don’t know of the existence of the registrar or the registry as they have no direct relationship which them. They only have a direct relationship with their reseller.
For a registrant and registrar to identify who the reseller is for a given registration at the registry, there is a desire to have reseller information represented in WHOIS and RDAP."

JG-Agreed that the introductions can be cleaned up and made more consistent.  I also agree that the reference to ICANN should be removed.  Your suggested text looks like a good starting point.

These are suggestions to continue, depending on the object discussion (Please forgive me if I forget the words "extension” or "mapping” or "command” somewhere, the current text confuses me):

For draft-ietf-regext-reseller:

„This document specifies a reseller object for version 1.0 of the Extensible Provisioning Protocol (EPP) [RFC5730] in order to facilitate provisioning and management of reseller information in a shared central repository"

For draft-ietf-regext-reseller-mapping:

"[ID.draft-ietf-regext-reseller] defines a reseller object to include reseller information in a shared central repository.
This document proposes an extension of [RFC5731], [RFC5732] and [RFC5733] to map an object to such reseller information.
The examples provided in this document are used for the domain object for illustration purposes. The host and contact object could be extended in the same way with the domain object.

A reseller object defined in [ID.draft-ietf-regext-reseller] SHOULD be created first.
The reseller information specified in this document SHOULD reference the existing reseller identifier and reseller name.”

-Par 3.1: "Reseller identifier provides the ID of the reseller of a sponsoring registrar…. All reseller objects are identified by a server-unique identifier"
This still confuses me a bit. I think it mixes up client/server with sponsoring registrar/registry.
It reads like a reseller can only be a reseller to one sponsoring registrar,

JG-A reseller may be a reseller of multiple registrars, but they would have a unique identifier per registrar.  There is a direct relationship between the registry and registrar and the reseller and registrar, so although a reseller may use multiple registrars, they would be managed independently by the registrar and therefore would have a unique identifier per registrar.  A reseller would have a unique reseller identifier per registrar and per registry.  For example, Reseller X that is a reseller of Registrar R1 and Registrar R2 that in turn interfaces with Registry Y1 and Y2, would at a minimum have 4 reseller identifiers (R1 to Y1, R1 to Y2, R2 to Y1, R2 to Y3), each with potentially matching reseller information (e.g. name).  If there was a central authoritative reseller registry with a unique identifier, like the IANA ID for ICANN accredited registrars, then a common identifier could be leveraged across sponsoring registrars, but such a registry does not exist and most likely will not exist.   The goal here is to define an object at the registry level that has a unique identifier that registrars can use to tag objects within a registry and that enables the reseller attributes to be managed by a registrar as an object to handle items like changing the reseller information, setting constraints, and setting policies.

What if he is reseller for 2 or more registrars?

JG-As described above a reseller would have one identifier per registrar and per registry.  The identifier is a surrogate key for a reseller instance and is not used outside of an individual registry.

Would it mean a new ID?

JG-Yes

Is it server or client, registry or registrar that assigns? Sponsoring registrar or client? Registry or server? Should there be a syntax definition?
I think it should read:

"All reseller objects are identified by a server-unique identifier called a "Reseller ID”.
The syntax of its corresponding element <reseller:id> is defined in this document/[ID.draft-ietf-regext-reseller]."

JG-Yes, it is a server-unique identifier and the ROID for a reseller that is globally unique may be a combination of the registry repository identifier, registrar identifier, and the unique reseller identifier for the registrar.

And then add the syntax definition in [ID.draft-ietf-regext-reseller], and words on who assigns the ID according to what rules (first-come-first-serve/registry defined/registrarid preceded?)

JG-It would be server defined but would be linked to the sponsoring registrar (client).  We could look to have the identifier, which needs to be server-unique, along with a globally unique identifier (ROID) that includes the full set of unique identifiers for a reseller.

I leave the rest of my questions and remarks till we have a suggestion for the reseller object, as I think that may change the current text quite a bit..

Regards,

- --
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392

Op 7 dec. 2016, om 09:35 heeft Linlin Zhou <[email-masked]<mailto:[email-masked]>> het volgende geschreven:

This is a very minor update, mostly just to keep the document alive to discuss on path of reseller object or entity object with multiple roles.

Regards,
________________________________
Linlin Zhou

From: internet-drafts<mailto:[email-masked]>
Date: 2016-12-07 16:30
To: [email-masked]<mailto:[email-masked]>
CC: regext<mailto:[email-masked]>
Subject: [regext] I-D Action: draft-ietf-regext-reseller-ext-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Registration Protocols Extensions of the IETF.

        Title           : Reseller Extension for the Extensible Provisioning Protocol (EPP)
        Authors         : Linlin Zhou
                          Ning Kong
                          Junkai Wei
                          Xiaodong Lee
                          James Gould
Filename        : draft-ietf-regext-reseller-ext-01.txt
Pages           : 18
Date            : 2016-12-07

Abstract:
   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.  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-ietf-regext-reseller-ext/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-regext-reseller-ext-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-reseller-ext-01

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/

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

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 17 Jan 2017 16:57:24 +0100

Op 9 jan. 2017, om 20:05 heeft Gould, James <[email-masked]> het volgende geschreven:

> JG-The existing title “Extensible Provisioning Protocol (EPP) Reseller Mapping” follows the model set by the EPP Object RFC’s, as in EPP Domain Name Mapping (RFC 5731), EPP Host Mapping (RFC), and EPP Contact Mapping (RFC 5733) for Object-level Extensions as defined in RFC 3735.

<snip>

> JG-The titles for Command-Response Extensions in RFC 3735 has not been as consist.  I believe it would be best to match the title convention of RFC 5910 for the Reseller Command-Response Extension as in “Reseller Extensions Mapping for the Extensible Provisioning Protocol (EPP)”.
>  I recommend to use the convention “Protocol Extensions Mapping” for a Protocol-level Extension.

Thank you for comparing, I hadn’t done all the consistency checking yet.
I agree with you that the object extension title is consistent and for the command-response extension it is best to follow the RFC 5910 convention as you suggest.

> JG-I believe to help with the mix up, the last sentence of the draft-ietf-regext-reseller-ext abstract can be modified to better reflect the purpose of the reseller command-response extension.

Since the document names and titles can be made consistent but not too revealing to non-epp-convention-experts, I agree that the abstract could be of much help in avoiding confusion.

> JG-Agreed that the introductions can be cleaned up and made more consistent.  I also agree that the reference to ICANN should be removed.  Your suggested text looks like a good starting point.

Ok.

> JG-A reseller may be a reseller of multiple registrars, but they would have a unique identifier per registrar.  There is a direct relationship between the registry and registrar and the reseller and registrar, so although a reseller may use multiple registrars, they would be managed independently by the registrar and therefore would have a unique identifier per registrar.

Ok, I understand this pragmatic approach. While it is a pity registration process wise that a reseller does not have one unique ID per registry, the idea behind one ID per registrar is because of the assignment of the ID’s for maintenance by different registrars.

My major concern for section 3 however is that it mixes up "server/client” (EPP syntax) and "registry/registrar” (ICANN/Domain registration syntax) which makes it confusing to read.
We should make a clear choice in what verbs to use. The above sentence could also read:

Ok, I understand this pragmatic approach. While it is a pity registration process wise that a reseller entity does not have one unique object per server, the idea behind one object ID per client is because of the assignment of the ID’s for maintenance by individual clients.

> JG-It would be server defined but would be linked to the sponsoring registrar (client).  We could look to have the identifier, which needs to be server-unique, along with a globally unique identifi…

If it is "server defined” as you intend, then there should be some text that says that.
It must be clear to server operators that they need to define their ID uniqueness algorithm as part of their local policy.
The server operator must define this algorithm itself as it is not defined in this document.
It must be clear the server defines the algorithm, and not the client.
And then it’s strange that the client needs to assign the ID according to the servers algorithm.
I would say that it’s then wise to leave the assignment of the ID to the server and not the client like it is done with handles.

The more general question I had is if this ultimate freedom for the server to choose an algorithm is wise or necessary or that it adds more complexity to the design choices the server operator needs to make.
We can give some examples to server operators on what sort of local uniqueness policy server operators could use, like first-come-first-served, fixed prefix per client-id, assigned by server algorithm, etc. , but my experience is that everybody will copy what the first implementer has done, as that is what people are used to.
(Registrars complain that every registry invents their own wheel).

This leaves us with the question of the option C (dedicated reseller role object) versus option D (generic role object for roles like resellers/dns-operators/etc.).
Is there any progress or suggestion from the authors on this?
Do we need to make another call on the mailing list to get a clearer consensus or discussion?
Do the authors want to do this themselves, or do they need any help from the chairs?

regards,

- --
Antoin Verschuren

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 18 Jan 2017 13:40:32 +0800

Dear Antoin,
Thanks for your review. Please see my feedback below.

Regards,

Linlin Zhou
 
From: Antoin Verschuren
Date: 2017-01-17 23:57
To: Gould, James
CC: Linlin Zhou; regext
Subject: Re: [regext] I-D Action: draft-ietf-regext-reseller-ext-01.txt
Op 9 jan. 2017, om 20:05 heeft Gould, James <[email-masked]> het volgende geschreven:

    <snip>

[Linlin] The name of "draft-ietf-regext-reseller-ext-01" will be modified to "Reseller Extensions Mapping for the Extensible Provisioning Protocol (EPP)" to be consistent with RFC 5910.

    Ok.

[Linlin] The abstract and introduction will be revised as suggested to make it more clear.

 

[Linlin] Some texts in draft-ietf-regext-reseller follow the pattern in RFC5731, RFC5732 and RFC5733. Maybe we could add some words just like the contact ID, for example, "Reseller identifiers are character strings with a specific minimum length, a specified maximum length, and a specified format. Reseller identifiers use the "clIDType" client identifier syntax described in [RFC5730]."

[Linlin] Actually no, we are pending on this choice.

[Linlin] Yes.

[Linlin] It may be helpful if chairs could propose a call on the mailing list to get more feedbacks. Thanks.

regards,

- -- 
Antoin Verschuren