Hi, As a co-author of these drafts and the one that pushed for the independent reseller object of “C”, I believe that “C” is the best choice with some explanation included below.
The driving reason for the creation of the reseller draft(s) is to enable the display of reseller information in RDDS at the registry level. Let me be clear that I believe it is an anti-pattern (RDDS Copy Authoritative Data) to push authoritative data down to a party to display as if it were authoritative. If the domain registry industry does support this anti-pattern, we may as well make it worth more than supporting RDDS. Option “A” simply treats the reseller information as an attribute of the provisioning objects (domain, host, contact, etc.) while option “C” treats the reseller information as objects. Items like ID uniqueness and reseller name changes is much more complex with the attribute model of “A”. I really haven’t thought about option “B” much, but considering that a reseller is a separate object from a contact, I don’t believe reusing the contact mapping makes sense. Option “C” supports RDDS and is extensible to support other reseller features like security, policy, financial, and reporting for registrars at the registry level. In summary, option “C” models the real world and makes implementation of the RDDS Copy Authoritative Data anti-pattern have some value in supporting optional reseller channel features at the registry level in the future. — JG [cid:77031CC3-BE7A-4188-A95F-D23115A30A4D@vcorp.ad.vrsn.com] James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> On Aug 15, 2016, at 3:54 AM, Linlin Zhou <zhoulin...@cnnic.cn<mailto:zhoulin...@cnnic.cn>> wrote: Dear all, The reseller drafts were suggested to have more reviews in last IETF meeting. All of the issues raised on the mailing list have been solved and updated in the latest version. Any more review or comments on these two drafts are appreciated. Regarding the draft-ietf-regext-reseller, we may have some choices of keep reseller information in my mind, A. an ID and a name only B. reuse contact object C. a independent reseller object, such as defined in draft-ietf-regext-reseller The RDAP may only need a name displayed in response but there are still some other information we need such as the contact or parent registrar of a reseller. So option A may not seem as a good choice. Some registries have already use contact to keep reseller information, but after discussion we found that reseller and contact are not totaly the same. The reseller is a object that could have one or more contacts and it has hierarchical structure. So option B is also not take into consideration. Finally we decided to define a reseller object to full fill the existing and possible future requirements., which is a flexible way for any changes. Thoughts? Regards, ________________________________ Linlin Zhou _______________________________________________ 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
