Antoin, Thank you for reviewing the drafts in detail. I’ve responded to some of the items below prefixed with “JG-“.
Thanks, — JG [cid:image001.png@01D26A81.631483E0] James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://verisigninc.com/> From: regext <regext-boun...@ietf.org> on behalf of Antoin Verschuren <i...@antoin.nl> Date: Sunday, January 8, 2017 at 1:55 PM To: Linlin Zhou <zhoulin...@cnnic.cn> Cc: regext <regext@ietf.org> 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 <zhoulin...@cnnic.cn<mailto:zhoulin...@cnnic.cn>> 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:internet-dra...@ietf.org> Date: 2016-12-07 16:30 To: i-d-annou...@ietf.org<mailto:i-d-annou...@ietf.org> CC: regext<mailto:regext@ietf.org> 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 regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org<mailto:regext@ietf.org> https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
