Dear working group, This is a request for action for you! Yes you! Reader of this mail, participant in this working group, or provisioning expert you forward this mail to.
Resulting from our last session in Seoul and follow up discussion on the mailinglist a few weeks ago, we still need to make a clear decision on advise for the authors of the reseller drafts in which direction the working group wants these documents to progress. So far, there has not been an overwhelming feedback. We realize that not every draft may attract your attention, but for this working group to produce any quality documents, it’s vital that drafts are reviewed and multiple angle advise is given. This is a request to please take some time to review the purpose of the reseller drafts. Detailed XML review is welcomed, but to answer this one question that the authors are desperately waiting on, quantity of opinions and a good generic overview of EPP and future registration processes is most important. To summarize where we left off in Seoul, and the question that we need an anser for is the choice between 2 options that we have left to register resellers in EPP. I have renamed these option 1 and 2 (resulting from options C and D during the session in Seoul). Option 1: A dedicated reseller object. This is the pragmatic approach. We define an object that is only for resellers, as that is the only question on the table now. + Only define attributes needed for resellers now. - Hard to reuse or adjust after data is provisioned, and future roles will need a newly defined dedicated object as well. Option 2: A generic organization object that can also be used for resellers. This is the more future proof approach, where an organization object can be used for resellers now, but can be used for provisioning future roles as well (think dns-operator, auditor, RDAP access) by tagging the relationship role the organization has with other objects. + No need to reinvent the wheel in the future, multiple roles can exist, fewer objects needed. - More work now to define generic attributes and which attributes are mandatory or optional for a reseller role to provision. A need to define relations to other objects. It boils down to this simple question: Do we think every role an organization has needs a separate object in EPP, or do we think an organization can have more than one role in the registration process and we can identify this role in relation to other objects in EPP. Please state your choice and motivation as an advise to the authors by answering to this thread. Be aware that other options have already been discussed and were rejected. So please don’t make the choice more difficult by inventing an option 3. Regards, - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 18 jan. 2017, om 06:40 heeft Linlin Zhou <zhoulin...@cnnic.cn> het volgende geschreven: > 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 <jgo...@verisign.com> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
