Hi Scott, > On 20 Nov 2024, at 12:38, Hollenbeck, Scott <shollenb...@verisign.com> wrote: > > [snip] > >> 2. There is no Privacy Considerations section. Given that this document >> pertains to transmission of email addresses, this should probably be >> corrected. > > [SAH] I just read RFC 6973. It mentions email addresses once, in Section > 5.2.1: > > "For example, an initiator's persistent use of the same device ID, > certificate, or email address across multiple interactions could allow > recipients (and observers) to correlate all of the initiator's communications > over time." > > I can capture that, but is there anything else that would need to be noted? > My immediate thought is that I could say something about the possibility of > these email addresses being disclosed by systems like WHOIS and RDAP. The use > of a privacy/proxy service can mitigate that risk. Anything else?
I don't believe there's much privacy prior art in EPP-related RFCs, and I don't think the additional email address that this document adds to the contact object data model deserves special consideration. I would suggest something along the lines of:- The content of <addlEmail:email> elements may be may be processed by EPP clients and servers in the same way as that of <contact:email> elements, including publication in directory services such as [RDAP](informative ref to STD 95). Most data protection regulations recognise email addresses as personal data, so any policies governing the collection, transmission and processing of contact information by EPP clients and servers should apply equally to <addlEmail:email> elements as to <contact:email> elements. G. -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
