Hi James, Thanks for your explanation. You just remind me of the first version of draft-ietf-regext-reseller-ext, we've put both ID and name in the extension. Then we found that there is no mechnism to keep the correctness of ID and name updates. So only the ID was kept in the latest version which is reffered to the reseller object identifier. As for option B, I think we have indicated that reseller and contact are not totally the same. It is a object that could have contacts object and has hierarchical relations. So we do not want to mix them together.
Regards, Linlin Zhou From: Gould, James Date: 2016-08-16 03:23 To: Linlin Zhou CC: regext Subject: Re: [regext] reseller drafts reviews 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 James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Aug 15, 2016, at 3:54 AM, Linlin Zhou <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 https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
