I asked many times who these registries are, I still fail to see broad consensus by registries to implement these extensions (I do not count silence as being "I agree" but just as "I do not care" or "I am not following these discussions, I do not know what to think about it"). Maybe they are thousands of them just anxiously waiting for this work to become an RFC (like it never happened in the past with registries implementing even core EPP documents before they became RFCs...), or maybe there are just not many of them needing all this...
There are many registries that participate in this working group that have spoken on the list or at the working group meetings on these extensions, so I’m really not sure what it means to have “broad consensus by the registries to implement”. — JG James Gould Distinguished Engineer jgo...@verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 5/28/18, 4:41 PM, "regext on behalf of Patrick Mevzek" <regext-boun...@ietf.org on behalf of p...@dotandco.com> wrote: On Mon, May 28, 2018, at 21:29, Antoin Verschuren wrote: > 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 ;-) I am not sure to see where in the text it says that formatted content is forbidden, can you pinpoint it to me? Also, I fail to see how any EPP extension would have any impact here (in the sense that: you can change what is displayed in whois irrespective to what happens on the EPP channel). > > 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. I asked many times who these registries are, I still fail to see broad consensus by registries to implement these extensions (I do not count silence as being "I agree" but just as "I do not care" or "I am not following these discussions, I do not know what to think about it"). Maybe they are thousands of them just anxiously waiting for this work to become an RFC (like it never happened in the past with registries implementing even core EPP documents before they became RFCs...), or maybe there are just not many of them needing all this... Noone knows but I have my ideas in which case we are. > It allows innovation. Innovations do not need RFCs, that can happen before. This would be a separate topic. > 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. Maybe. At least this is not shown by discussions here, which is sad. Also, I am still not sure the proposed extensions solve all of these problems anyway. Especially if you take into account the drawbacks as any solution has both benefits and drawbacks, nothing is a pure win. > 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. Maybe. I am not convinced by the data proposed on the table. There may be a lot more elsewhere, but here I do not see. Anyway, this is moot. The extensions will go forward and become an RFC and then we will be able to jauge really the interest by registries and how it is implemented... -- Patrick Mevzek _______________________________________________ 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
