[gtld-tech] EPDP recommendations and EPP

[Roger D Carney]

Good Morning,


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”.



Though I want to stress that I believe this is just the quick/short term solution and that I believe that the correct way to resolve this is to “update” RFC 5733. At minimum to make city and cc optional but we should really look at what is needed for improving data privacy/protection on the whole. I also believe this work is extremely important and would like to see this as one of the items that the REGEXT group picks up and starts working immediately.




Thanks
Roger


From: gtld-tech <gtld-tech-bounces at icann.org> On Behalf Of Gould, James via gtld-tech
Sent: Thursday, February 28, 2019 7:51 AM
To: Hollenbeck, Scott <shollenbeck at verisign.com>; gavin.brown at centralnic.com; gtld-tech at icann.org
Subject: Re: [gtld-tech] EPDP recommendations and EPP


Scott,



There are a few issues that we need to address, which include:



  1.  Technical Contact – Only 3 optional fields of Name, Phone, and Email are defined in EPDP Team Recommendation #7.  Is the collection of the additional RFC 5733 disallowed?
  2.  Registrant Contact – All of the Registrant data fields are defined as optional in EPDP Team Recommendation #7.  This means that both Technical Contacts and Registrant Contacts would need to get around the required <contact:name>, <contact:city>, and <contact:cc> elements in RFC 5733.
  3.  Contacts Don’t Have a Type – Contacts are created without a type in RFC 5733, where type is based on the link from the domain name.  Since a Contact is an object, it could be a Registrant and Technical contact for a single domain or for many domains.  Who would apply the policy for what fields are set or not set (client, server, or both)?  My recommendation is for the client to apply the policy, since the client has the relationship with the registrant.



To meet the policy, my recommendation is to support RFC 5733 with placeholder values for the <contact:name>, <contact:city>, and <contact:cc> elements to indicate non-existence, to have the servers be flexible to the contact fields set by the client, and to have the clients implement the policy related to what fields of a contact are set based on the type of the contact.  This is not a perfect solution, but it would allow implementing the policy without a great amount of dependencies and complexity (e.g., parallel contact mappings, adding typing to contacts, adding link type rules, and raising the issue of inconsistent server policies).



I agree with your proposal of option 3, with the additional placeholder text for the required <contact:name> element, the server accepting a flexible number of contact fields (empty or placeholder) for all contacts, and the client implementing the policy.



—



JG







James Gould

Distinguished Engineer

jgould at Verisign.com<mailto:jgould at Verisign.com>



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com <http://verisigninc.com/>



On 2/28/19, 7:53 AM, "gtld-tech on behalf of Hollenbeck, Scott via gtld-tech" <gtld-tech-bounces at icann.org on behalf of gtld-tech at icann.org<mailto:gtld-tech-bounces at icann.org%20on%20behalf%20of%20gtld-tech at icann.org>> wrote:



    > -----Original Message-----

    > From: gtld-tech <gtld-tech-bounces at icann.org<mailto:gtld-tech-bounces at icann.org>> On Behalf Of Gavin Brown

    > Sent: Wednesday, February 27, 2019 4:41 AM

    > To: gtld-tech at icann.org<mailto:gtld-tech at icann.org>

    > Subject: [EXTERNAL] [gtld-tech] EPDP recommendations and EPP

    >

    > Hi all,

    >

    > The EPDP final report says that, if a domain name has a technical contact

    > (whose information is different from the registrant's), the only data that

    > registrars should send to registries are the technical contact's name, email

    > address, and phone number (if any).

    >

    > Assuming that technical contacts should still be created and managed as RFC

    > 5733 contact objects, and also assuming that this recommendation is adopted

    > without change, it poses a challenge, because the RFC requires all contact

    > objects to have <city> and <cc> elements.

    >

    > I've been thinking about how this could be resolved, here are some ideas (in

    > descending order of nastiness):

    >

    > * write a new RFC which updates RFC 5733 to make the <city> and <cc>

    > elements optional

    >

    > * write a new EPP extension which makes the technical contact's name,

    > email address, and phone number directly attributes of the the domain

    > name rather than a contact object

    >

    > * 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.

    >

    > Any thoughts?



    I tend to prefer the last option. It doesn't have any dependencies on pushing documents through the IETF, and it doesn't get us into developing policy-specific specifications.



    Scott


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gtld-tech/attachments/20190301/8148936c/attachment-0001.html>