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? -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ +44.7548243029 CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.
Hi Gavin, Il 27/02/2019 10:40, Gavin Brown ha scritto:
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?
Make RFC5733 <addr> element optional. mario -- Dr. Mario Loffredo Servizi Internet e Sviluppo Tecnologico CNR - Istituto di Informatica e Telematica via G. Moruzzi 1, I-56124 PISA, Italy E-Mail: mario.loffredo@iit.cnr.it Phone: +39.0503153497 Web: http://www.iit.cnr.it/mario.loffredo
On 27/02/2019 10:10, Mario Loffredo wrote:
Hi Gavin,
Il 27/02/2019 10:40, Gavin Brown ha scritto:
[snip]
Any thoughts?
Make RFC5733 <addr> element optional.
That would require a standards-track RFC, and since it would result in an XML schema update, probably a namespace version update as well (i.e. urn:ietf:params:xml:ns:contact-1.0 => urn:ietf:params:xml:ns:contact-1.0 => urn:ietf:params:xml:ns:contact-1.1). G. -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ +44.7548243029 CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.
I believe there are many technical alternatives available for us to meet the policy. The need for a standards-track RFC is an open question. — JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 2/27/19, 8:28 AM, "gtld-tech on behalf of Gavin Brown" <gtld-tech-bounces@icann.org on behalf of gavin.brown@centralnic.com> wrote: On 27/02/2019 10:10, Mario Loffredo wrote: > Hi Gavin, > > Il 27/02/2019 10:40, Gavin Brown ha scritto: >> >> [snip] >> >> Any thoughts? > > Make RFC5733 <addr> element optional. That would require a standards-track RFC, and since it would result in an XML schema update, probably a namespace version update as well (i.e. urn:ietf:params:xml:ns:contact-1.0 => urn:ietf:params:xml:ns:contact-1.0 => urn:ietf:params:xml:ns:contact-1.1). G. -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ +44.7548243029 CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.
Gavin, I ran across this issue for the relaxed validation that came out of the thick policy. Since we implement full schema validation and we provide an EPP SDK that does the same, I had to create a modified XML schema that can be used on server side and client side. Can someone from the EPDP explain why the technical contact will not follow the EPP RFC? A contact is created without a type in EPP, so having different contact collection requirements by type does not work. It would be much easier for everyone if the required fields for all contact types matched the required fields of the EPP RFC; otherwise we will run into policy that is overriding RFC compliance issues and implementation problems for both the client and the server. We could adjust what fields are displayed by type in RDAP instead of in EPP. Keep the minimum fields collected consistent and compliant with the RFC and adjust what fields that are returned in the RDAP responses. Jim Sent from my iPhone
On Feb 27, 2019, at 4:41 AM, Gavin Brown <gavin.brown@centralnic.com> wrote:
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?
-- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ +44.7548243029
CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.
It would be much easier for everyone if the required fields for all contact types matched the required fields of the EPP RFC; otherwise we will run into policy that is overriding RFC compliance issues and implementation problems for both the client and the server.
To me that would be the tail wagging the dog. Technology has to support policy, not vice versa.
We could adjust what fields are displayed by type in RDAP instead of in EPP. Keep the minimum fields collected consistent and compliant with the RFC and adjust what fields that are returned in the RDAP responses.
The EPDP report explicitly describes what data elements are *transferred from registrar to registry*, not what is *displayed* in RDDS. Transferring those elements would be in breach of the recommendation, even if the fields were not displayed. G. -- Gavin Brown Chief Technology Officer CentralNic Group plc (LSE:CNIC) Innovative, Reliable and Flexible Registry Services for ccTLD, gTLD and private domain name registries https://www.centralnic.com/ +44.7548243029 CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: 35-39 Moorgate, London, EC2R 6AR.
On 27 Feb 2019, at 06:40, Gavin Brown <gavin.brown@centralnic.com> wrote:
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.
I think the 3rd option is the easiest at this point, but I suggest "REDACTED DATA" for the city field, And I believe we should extend that to sp (state/province). For cc I like XX since XA to XZ are user-assigned in ISO 3166-1 alpha-2. Rubens
-----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
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@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
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@icann.org> On Behalf Of Gould, James via gtld-tech Sent: Thursday, February 28, 2019 7:51 AM To: Hollenbeck, Scott <shollenbeck@verisign.com>; gavin.brown@centralnic.com; gtld-tech@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@Verisign.com<mailto: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<mailto:gtld-tech-bounces@icann.org%20on%20behalf%20of%20gtld-tech@icann.org>> wrote: > -----Original Message----- > From: gtld-tech <gtld-tech-bounces@icann.org<mailto:gtld-tech-bounces@icann.org>> On Behalf Of Gavin Brown > Sent: Wednesday, February 27, 2019 4:41 AM > To: gtld-tech@icann.org<mailto: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
participants (6)
-
Gavin Brown -
Gould, James -
Hollenbeck, Scott -
Mario Loffredo -
Roger D Carney -
Rubens Kuhl