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

[Mario Loffredo]

Il 04/03/2019 21:51, Andrew Newton ha scritto:

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


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

On Fri, Mar 1, 2019 at 10:54 AM Patrick Mevzek  wrote:

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
   p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


--
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.loffr...@iit.cnr.it
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Patrick Mevzek]

On Tue, Mar 5, 2019, at 07:42, Gavin Brown wrote:
> > 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).
> 
> 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  element in domain objects.
> 
> 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.

> Could a registrar determine whether a given contact object was a "full"
> contact or a "light" without performing an  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...

> Furthermore, my research[1] indicates that the "one-to-many"
> relationship between domains and contacts that is implicit in EPP does
> 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.

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

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

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.

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

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
  p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Gavin Brown]

On 01/03/2019 15:03, Patrick Mevzek wrote:
> [snip] 
>
> 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).

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

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

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.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Andrew Newton]

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

On Fri, Mar 1, 2019 at 10:54 AM Patrick Mevzek  wrote:
>
> 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
>   p...@dotandco.com
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Roger D Carney]

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  On Behalf Of Patrick Mevzek
Sent: Friday, March 1, 2019 9:55 AM
To: regext@ietf.org
Subject: Re: [regext] [gtld-tech] EPDP recommendations and EPP

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
  p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Patrick Mevzek]

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
  p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Roger D Carney]

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  On Behalf Of Patrick Mevzek
Sent: Friday, March 1, 2019 9:03 AM
To: regext@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  and  elements to contain 
> placeholder values, such as: - and XX 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
  p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

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

[Patrick Mevzek]

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  and  elements to contain 
> placeholder values, such as: - and XX 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
  p...@dotandco.com

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] [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  and  elements to contain placeholder values, such 
as: - and XX 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  On Behalf Of Gould, James via 
gtld-tech
Sent: Thursday, February 28, 2019 7:51 AM
To: Hollenbeck, Scott ; gavin.br...@centralnic.com; 
gtld-t...@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 
, , and  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 , , and  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  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

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



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



> -Original Message-

> From: gtld-tech 
mailto:gtld-tech-boun...@icann.org>> On Behalf Of 
Gavin Brown

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

> To: gtld-t...@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  and  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  and 

> 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  and  elements to 
contain

> placeholder values, such as: - and XX 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


_