Linlin,
On 15 Aug 2016, at 09:54, 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 This seems to be the minimum-viable-product. However I can image you might want to add more fields, at least an email address for contacting the reseller…. so we need some sort of object. B. reuse contact object This would be my personal preferred object, however in our case the RFC5733 contact object did not have all the required fields…. so we need some sort of contact object or reseller object C. a independent reseller object, such as defined in draft-ietf-regext-reseller Given the use-case this might seem interesting for the specific reseller use-case. However there are more use-cases on the horizon (e.g. 3rd party DNS operator). So are we going for a reseller specific solution this is the best (with a minimum set of required fields). However we might want to consider creating a more generic extension (like the entity in RDAP) which we can use for other objects to be labelled with. 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. If this is the ICANN policy (haven’t look for it yet though), we might want to consider adding the name as an optional field to the draft-ietf-regext-reseller-ext draft. So implementers have 2 choices. Implement only draft-ietf-regext-reseller-ext with the name field (so the domains can be simply labelled with a reseller name) or implement the full EPP object with the draft-ietf-regext-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? Conclusion: Although at first it seems a little bit of overkill I came to the conclusion Option C is the best option, with the remarks that we need a minimum set of required fields. And optionally we could add the name back into the draft-ietf-regext-reseller-ext if this makes it less effort to comply with ICANN policies for implementers. Gr, Rik
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
