Op 27 mei 2018, om 21:23 heeft Patrick Mevzek <p...@dotandco.com> het volgende geschreven:
> This is covered I think in ICANN world by section 1.4.2 of the whois > specification: > > "Additional data elements can be added at the end of the text format outlined > below.” Ah yes, let’s take the solution of "we can put everything in one non-parseble TXT record like DNS can do too if we fail proper design and really want to” ;-) Sorry for the sarcasm Patrick, but that one was a too open goal ;-) > This is all true, probably, but how does it goes from there to "these > operators need to exist as object in the registry database and be made under > control of the registrars"? This sidestep many other points, like, one > dns-operator for example, could be operator for domain names sponsored by > registrar A and registrar B. Will both registrar A and B need to create an > organization object for this same and only dns-operator organization? What > exactly does this benefit to? That was my question and worry too, and the answer unfortunately is yes, as ownership of an object needs to be clear to prevent hijacking or no responsibility for data. It’s a choice between two bad’s I agree, but having an organization in the DB more than once under different registrars with different ID’s is less bad than having objects nobody maintains or fights over. > In a GDPR world you need more and more to be very specific about the data you > collect, its use, and how you keep it. While it does not apply exactly as is > here, I still fail to see why the registry database need to be populated with > all this data. You forget to see that this will benefit registries that want to do the right thing where they are now limited by protocol. It allows innovation. I’ve seen registries that want to add reseller data in whois/RDAP at their registrar’s request, registries that want dns-operators to be able to roll their registrant’s DNSSEC keys, they want to be transparent as tho which organization has extended RDAP access, etc. And the registrars are still in control over who they trust with these limited registry credentials, but in the end they will save costly customer support and have more extended service if they automate. > And while I can understand James argument and design I think we are making > things over complex without direct benefit, for what I understood the only > use case applicable on the table is "storing reseller data in registry > database (and maybe showing it in whois)". > For such a simple need, I think we are over-designing stuff. If that were the only use case, I would agree with you. It may look like overdesigning now if that were the only use case, but if we don’t add structure now, it will be hard to go back once unstructured objects are already populated. We took the challenge of doing more work now, to have quicker innovation later. And I see more use cases than just the reseller one. regards, - -- Antoin Verschuren Tweevoren 6, 5672 SB Nuenen, NL M: +31 6 37682392 - -- 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
