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 protected]> 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. [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. 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 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. [Linlin] The abstract and introduction will be revised as suggested to make it more clear. 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. 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. 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). [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]." 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? [Linlin] Actually no, we are pending on this choice. Do we need to make another call on the mailing list to get a clearer consensus or discussion? [Linlin] Yes. Do the authors want to do this themselves, or do they need any help from the chairs? [Linlin] It may be helpful if chairs could propose a call on the mailing list to get more feedbacks. Thanks. regards, - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392
_______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
