Hi Linlin, I must admit I haven’t compared the proposed reseller structure to that of a registrar, but what happens when a reseller suddenly wants to become a registrar (or a registrar that will become a reseller under a larger registrar)? Use cases that I think happen regularly. Is it just a matter of adding or removing a reseller:parentId? I’d say option D to reuse the same fields for a reseller as a registrar, but with business logic that makes a lot of fields optional that would be mandatory for a registrar without a parentId. I mean, a reseller is an entity, just like a registrar but with different rights and obligations towards the registry, right? Would that work? What is shown in RDAP is another matter, but at least we don’t need to reinvent and maintain a new structure, and we only need to agree on which fields are optional for which role, which may even be local policy. Also thinking ahead of the possibility to administer 3th party dns-operators with limited rights agreed upon by the parent registrar, which might encounter the same question.. Just a thought.
- -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 Op 15 aug. 2016, om 09:54 heeft Linlin Zhou <zhoulin...@cnnic.cn> het volgende geschreven: > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
