[gtld-tech] [regext] EPDP recommendations and EPP
Roger D Carney
rcarney at godaddy.com
Fri Mar 1 15:22:13 UTC 2019
Thanks for the comments Patrick. I agree about the pollution of placeholders and that is one reason why I think it can only be used as a temporary solution.
I am not sold on creating a "new object." Another way to do the same intention, to me this will just get convoluted for implementers (look here unless you should look over there). To me this is just creating a new mechanism to avoid fixing a problem in the current mechanism.
I am not sure how improving RFC 5733 to be more flexible and data privacy/protection aware is a detriment to anyone using EPP. Anyone using 5733 needs to be acutely aware of data "processing" and would greatly benefit from a more flexible technical solution.
From: regext <regext-bounces at ietf.org> On Behalf Of Patrick Mevzek
Sent: Friday, March 1, 2019 9:03 AM
To: regext at ietf.org
Subject: Re: [regext] [gtld-tech] EPDP recommendations and EPP
On Fri, Mar 1, 2019, at 15:39, Roger D Carney wrote:
> I think I am in agreement with most people on this, that option 3 (or
> C, whatever it is called) is the best short term solution “define a
> "convention" that allows the <city> and <cc> elements to contain
> placeholder values, such as: <city>-</city> and <cc>XX</cc> which pose
> no data protection issues”.
I am completely againts such placeholders.
While they are the easy fast solution, they just pollute databases with useless data.
Instead of updating RFC5733 I would suggest creating a new object, a "light (or shallow) contact" which is like a contact currently, just with less fields.
Domains could use "full contacts" (the ones we know today) or light contacts (the new ones).
One has to keep remembering that EPP is not just used by gTLDs, so any change has to be done in such a way that it does not impact negatively any operation done outside of ICANN circles.
pm at dotandco.com
regext mailing list
regext at ietf.org
More information about the gtld-tech