Scott,

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

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

—

James Gould

Distinguished Engineer

jgould@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@icann.org on behalf of gtld-tech@icann.org> wrote:

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

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

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

> To: gtld-tech@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