Subject: Re: [regext] [gtld-tech] EPDP recommendations and EPP

From: Roger D Carney <[email-masked]>
Date: Fri, 1 Mar 2019 14:39:22 +0000

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 <[email-masked]> On Behalf Of Gould, James via gtld-tech
Sent: Thursday, February 28, 2019 7:51 AM
To: Hollenbeck, Scott <[email-masked]>; [email-masked]; [email-masked]
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

[email-masked]<mailto:[email-masked]>

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" <[email-masked] on behalf of [email-masked]<mailto:[email-masked][email-masked]>> wrote:

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

    > From: gtld-tech <[email-masked]<mailto:[email-masked]>> On Behalf Of Gavin Brown

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

    > To: [email-masked]<mailto:[email-masked]>

    > 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

---

From: "Patrick Mevzek" <[email-masked]>
Date: Fri, 01 Mar 2019 10:03:11 -0500

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.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Roger D Carney <[email-masked]>
Date: Fri, 1 Mar 2019 15:22:13 +0000

Good Morning,

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.

Thanks
Roger

-----Original Message-----
From: regext <[email-masked]> On Behalf Of Patrick Mevzek
Sent: Friday, March 1, 2019 9:03 AM
To: [email-masked]
Subject: Re: [regext] [gtld-tech] EPDP recommendations and EPP

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.

--
  Patrick Mevzek
  [email-masked]

_______________________________________________
regext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/regext

---

From: "Patrick Mevzek" <[email-masked]>
Date: Fri, 01 Mar 2019 10:54:31 -0500

On Fri, Mar 1, 2019, at 16:22, Roger D Carney wrote:
> 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.

If this is implemented, it will become permanent and there will be nothing else replacing it later.
 
> 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).

I do not feel that convoluted and even if it is the case we already have many of them:
- host attributes vs host objects
- secDNS keyData vs dsData
etc.

> To me this is just creating a 
> new mechanism to avoid fixing a problem in the current mechanism.

There is no problem in current mechanism. ccTLDs are all "fine" with it.
Right now we are discussing (in multiple places so that makes participating difficult)
things that will only apply to gTLDs.

I really do not want again to give everyone's impression that we are tailoring
a protocol to a very specific case just because the major vocal interests are there.

In short, if gTLDs need another contact model because the one in RFC5733 is not fitting
today anymore, it seems the clearer and simpler to me to just define a new model
for contacts.

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

You can not "improve" RFC 5733. You will need to create a new namespace,
like "contact-2.0"
At which point it is quite the same for implementors because any client
with multi registries need will need to handle both namespaces (you can not expect
all registries, specially non gTLD ones, just moving to your new schema, even
if it is a strict superset of previous ones, because they will have absolutely 0
reasons, technical or economical, to do the change),
so if you have
"contact-1.0" and "contact-2.0" namespaces to handle
OR
"contact-1.0" and "lightContact-1.0" (or "shallowContact-1.0" or "gtldContact-1.0" or whatever)
it is basically the same amount of work, but second option seems better to me
for multiple reasons.

And again, there is a huge non technical difference.
If we give again the impression to change the EPP just to suite gTLD needs,
we should not lament later on the state of EPP worldwide and why not everyone
follows the standard to the letter, or best current practices, etc.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Roger D Carney <[email-masked]>
Date: Fri, 1 Mar 2019 17:20:02 +0000

Good Morning,

Thanks for the comments Patrick.

Agreed, another one of the concerns going with placeholders is that to some, it will lessen the urgency to solve the underlying issue.

Not speaking specifically to the examples you gave on multiple mechanisms, I still believe that adding an additional contact mapping will increase implementation complexity that is not needed, more below.

As far as tailoring the protocol, it seems to me that the current RFC 5733 has been tailored. I am not sure why 5733 required these fields to exist in the first place, I assume it was discussed when it was written many years ago and it was decided for some reason these fields be treated special, but I don't see a technical reason to treat them differently. I don't think the idea of making the EPP Contact Mapping more flexible is a gTLD specific solution.

Thanks for digging deeper into what it takes to "improve" the current mechanism. As Gavin mentioned in his original email, this would require a new RFC be created and you have provided some more logistics to that effort. As you mention, there may be clients that may need to support both namespaces, but for servers that choose to use the new namespace the interface on both sides would be less complex than having two mapping mechanisms. Servers could have the option of supporting the namespace that is appropriate for them (though I assume for gTLDs ICANN would update policy to use the new namespace).

Thanks
Roger

-----Original Message-----
From: regext <[email-masked]> On Behalf Of Patrick Mevzek
Sent: Friday, March 1, 2019 9:55 AM
To: [email-masked]
Subject: Re: [regext] [gtld-tech] EPDP recommendations and EPP

 

There is no problem in current mechanism. ccTLDs are all "fine" with it.
Right now we are discussing (in multiple places so that makes participating difficult) things that will only apply to gTLDs.

I really do not want again to give everyone's impression that we are tailoring a protocol to a very specific case just because the major vocal interests are there.

In short, if gTLDs need another contact model because the one in RFC5733 is not fitting today anymore, it seems the clearer and simpler to me to just define a new model for contacts.

> greatly benefit from a more flexible technical solution.

You can not "improve" RFC 5733. You will need to create a new namespace, like "contact-2.0"
At which point it is quite the same for implementors because any client with multi registries need will need to handle both namespaces (you can not expect all registries, specially non gTLD ones, just moving to your new schema, even if it is a strict superset of previous ones, because they will have absolutely 0 reasons, technical or economical, to do the change), so if you have "contact-1.0" and "contact-2.0" namespaces to handle OR "contact-1.0" and "lightContact-1.0" (or "shallowContact-1.0" or "gtldContact-1.0" or whatever) it is basically the same amount of work, but second option seems better to me for multiple reasons.

And again, there is a huge non technical difference.
If we give again the impression to change the EPP just to suite gTLD needs, we should not lament later on the state of EPP worldwide and why not everyone follows the standard to the letter, or best current practices, etc.

--
  Patrick Mevzek
  [email-masked]

---

From: Andrew Newton <[email-masked]>
Date: Mon, 4 Mar 2019 15:51:19 -0500

I don't have much skin in the game, but I agree with Patrick on this.
Especially with the notion that there are non-gTLD players in this
space.

Also, is EPDP the law now? Is there not time to implement the right solution?

-andy

---

From: Gavin Brown <[email-masked]>
Date: Tue, 5 Mar 2019 12:42:13 +0000

On 01/03/2019 15:03, Patrick Mevzek wrote:
> [snip] 

I can't see how this would work. Let's say we define a new object
mapping for "light" contacts, with its own namespace, to be used with
just the <contact type="tech"> element in domain objects.

Could such contacts be used with domains without an update to RFC 5731?

Could a registrar determine whether a given contact object was a "full"
contact or a "light" without performing an <info> command?

I think this would cause a huge amount of confusion and pain.

Furthermore, my research[1] indicates that the "one-to-many"
relationship between domains and contacts that is implicit in EPP does
not reflect reality, so defining a new "first class" EPP object just
perpetuates the data management issues that registries currently have to
deal with.

If we're going to write a new RFC just for technical contacts then I
would suggest that it should define an extension to the domain object,
since that is (a) simpler for clients and servers to implement and (b)
more accurately maps to the way the data is represented and handled
outside of EPP.

> be done in such a way that it does not impact negatively any operation done outside

It seems to me that updating RFC5733 would have a bigger impact outside
the gTLD world than either of the other options I've proposed:
presumably many ccTLD registries rely on the the XML schema in RFC 5733
to enforce their data collection policies, but if we change that schema,
and they unknowingly update their implementation, then their data
collection policy will be changed without them knowingly accepting it.

G.

[1]:
http://regiops.net/wp-content/uploads/2017/05/ROW6_Brown_Contact-Object-Management-by-Registrars.pdf

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

---

From: "Patrick Mevzek" <[email-masked]>
Date: Tue, 05 Mar 2019 09:38:49 -0500

> Could such contacts be used with domains without an update to RFC 5731?

Probably not, but so what? You can not just "update" RFC 5733, you will need to write
a new one, with a new XML schema, and hence you will need to update RFC 5731
as well.

> contact or a "light" without performing an <info> command?

Since the registrar created the object in the first place, I do not see
the issue there.
Also, there may not be a need to mix contacts: a registry can decide to use
only one form (if the new schema is constructed in such a way to fit all contacts
cases), and hence there is no question.

> I think this would cause a huge amount of confusion and pain.

Using placeholders creates even more confusion and just tries to go around
a schema that does not fit its use anymore...

> not reflect reality, 

And yet in the nearly 20 years of existence of EPP noone came forward to
propose working on this...
Please do not use the result of an ICANN *policy* to change the protocol
while implying this is needed for all EPP servers as it is was an EPP deficiencies
in the first place.
It may well be an EPP deficiency and if so it needs to be tackled separately,
but that is really not the correct channel at this point.

> If we're going to write a new RFC just for technical contacts then I

I never suggested "just for technical contacts". On the contrary, if defined
properly, the schema could be used, in place, for all contacts. For some registries,
like gTLDs ones bound by specific contracts, they could then just use those
instead of the current "contact-1.0" ones.

> more accurately maps to the way the data is represented and handled

This would create even more confusion, as clearly today the hosts as objects
vs hosts as attributes is one of the major pain point of any registrar
(again, one has to try to be in registrar shoes, for a registry everything
is simple, it has one case to handle, its own, and it  can often forget that
its registrar have other cases to handle too, so all the complexities finish
on the registrars' shoulders)
 
> the gTLD world than either of the other options I've proposed:

I am still waiting on non-gTLD registries to participate in the subject
and to see how much they will be happy to see EPP changed for everyone
*just because* ICANN enacted some new policy.

> collection policy will be changed without them knowingly accepting it.

You can not "change that schema". You need to create a new namespace.

Besides, I have no idea what you mean. Registries policies on contact data
go far beyond what is in the EPP schema, in the sense of validation done
and constraints.
You already have far more problematic issue like "id" being either ignored
or just refused (while being mandatory in the schema), the "int" vs "loc" issue,
the semantics of "update" on "postalAddr", etc.

And again, if a new contact schema appears, registries that want it use it,
those that want to keep the current contact-1.0 keep it, and all is fine
(besides the complexities for registrars, but obviously they will have
to deal with it in any way, placeholders introduce their own complexities
as they will be hardcoded in every piece of code, so that the value is
not offered for edition for example, etc.)

-- 
  Patrick Mevzek
  [email-masked]

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 7 Mar 2019 10:21:37 +0100

> I don't have much skin in the game, but I agree with Patrick on this.

+1

ccTLDs are not directly affected by EPDP recommendations at present but 
it could be in the future since ccTLDs might meet the requirements 
coming from those registrars which are also gTLDs registrars.

In my opinion, if there was enough time according to the deadline to 
implement EPDP recommendations, a better solution than using placeholder 
values should be found.

As suggested by Patrick, the definition of a "light contact" object 
might be enough to bypass contact-1.0 schema constraints.

In my view, the new schema could define the operations (i.e. create and 
info) together with a type to be used as a response extension (e.g. in a 
domain info) in order to list the light contacts' ids.

In this way, both domain-1.0 and contact-1.0 schemas could remain unchanged.

If there was absolutely no time, even if RegExt WG fast-tracked the 
light contact (or whatever else) standardization process, I agree with 
Roger about using placeholder values as a temporary solution.

Regards,

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: [email-masked]
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo