<div dir="ltr"><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><font color="#000000">Hadia,</font></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><font color="#000000"><br></font></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><font color="#000000">Thanks.  Let me clarify and perhaps apologize slightly.  I've been asserting  there should be a dictionary of defined data elements, i.e. the Data Dictionary, that is an independent structure that is maintained under IETF and/or IANA auspices.  This doesn't actually exist yet in an explicit form.  There are, however, the main elements of the Data Dictionary embodied in RDAP and EPP documents and elsewhere.  I am working with others to put the Data Dictionary into the proper form and have it documented and maintained through the regular processes.</font></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><font color="#000000"><br></font></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><font color="#000000">That said, the right posture for this WG and for the GNSO in general is to view the Data Dictionary as something that is part of the general Internet landscape and not solely a creation of the ICANN contracting process and/or the GNSO policy  process.  (Whether and how to use data elements in the Data Dictionary is, of course, a separate matter.  With respect to whether and how the contracted parties will use the data elements, this is indeed properly within the scope of the contracts and GNSO policy process.)</font></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><font color="#000000"><br></font></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><font color="#000000">We can probably choose whether to use one data element, KIND, and extend the allowed values or two data elements.  As I said briefly in my note, the two approaches are essentially equivalent with only mild pros and cons for each.  The main argument in favor of using just one data element is the various combinations are documented and managed together.  The main argument against using just one data element is the added complexity of the data structure.  The main argument in favor of two data elements is the reduction in complexity of the values.  The main argument against two data elements is the slightly increased confusion that will arise from having the notion of "personal" appear in two places.  The meanings will be slightly different but it will require some explanation to people who encounter it for the first time.</font></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><font color="#000000"><br></font></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><font color="#000000">Either approach will work.  Even better, each registrar can choose whichever it likes in their internal implementations.  The data can be mapped back and forth between the two approaches.  The only thing that needs to be nailed down for everyone is whether one or two data elements is used when transferring the data from one organization to another.</font></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><font color="#000000"><br></font></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><font color="#000000">I will say a bit more about the use and interaction among the possible values in my reply to Volker next.</font></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><font color="#000000"><br></font></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><font color="#000000">Steve</font></div><div class="gmail_default" style="font-family:arial,sans-serif;font-size:small"><font color="#000000"><br></font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 19, 2021 at 7:30 AM Hadia Abdelsalam Mokhtar EL miniawi <<a href="mailto:Hadia@tra.gov.eg" target="_blank">Hadia@tra.gov.eg</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div>
<p class="MsoNormal">Hi Steve,<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Thank you for the clear proposal, I wanted to ask how would you extend the allowed values for KIND and if you were to add a new data element would this need to be through the IETF working group?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Hadia<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><b>From:</b> Gnso-epdp-team <<a href="mailto:gnso-epdp-team-bounces@icann.org" target="_blank">gnso-epdp-team-bounces@icann.org</a>>
<b>On Behalf Of </b>Steve Crocker via Gnso-epdp-team<br>
<b>Sent:</b> Thursday, August 19, 2021 5:16 AM<br>
<b>To:</b> Drazek, Keith <<a href="mailto:kdrazek@verisign.com" target="_blank">kdrazek@verisign.com</a>><br>
<b>Cc:</b> <a href="mailto:gnso-secs@icann.org" target="_blank">gnso-secs@icann.org</a>; EPDP <<a href="mailto:gnso-epdp-team@icann.org" target="_blank">gnso-epdp-team@icann.org</a>><br>
<b>Subject:</b> Re: [Gnso-epdp-team] Proposed Small Team on Rec #3 and Standardized Data Element Values<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;font-family:Arial,sans-serif;color:black">Keith, et al,</span><span style="font-size:12pt;font-family:Arial,sans-serif"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;font-family:Arial,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;font-family:Arial,sans-serif;color:black">Attached is my suggestion regarding capturing both the registrant's legal status (KIND) and whether the registrant data contains personal information.</span><span style="font-size:12pt;font-family:Arial,sans-serif"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;font-family:Arial,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;font-family:Arial,sans-serif;color:black">Thanks,</span><span style="font-size:12pt;font-family:Arial,sans-serif"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;font-family:Arial,sans-serif"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;font-family:Arial,sans-serif;color:black">Steve</span><span style="font-size:12pt;font-family:Arial,sans-serif"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;font-family:Arial,sans-serif;color:blue"><u></u> <u></u></span></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Wed, Aug 18, 2021 at 6:03 PM Steve Crocker <<a href="mailto:steve@shinkuro.com" target="_blank">steve@shinkuro.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<p class="MsoNormal">Excellent!  Count me in. I will try to send a short note tonight. <u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt">Steve <u></u><u></u></p>
<div>
<p class="MsoNormal">Sent from my iPhone<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal" style="margin-bottom:12pt">On Aug 18, 2021, at 5:03 PM, Drazek, Keith via Gnso-epdp-team <<a href="mailto:gnso-epdp-team@icann.org" target="_blank">gnso-epdp-team@icann.org</a>> wrote:<u></u><u></u></p>
</blockquote>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">Hi all,<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">As we work to complete our Final Report, the Leadership team and Staff would like to suggest a very focused bit of additional work related to proposed Rec #3 and the potential standardized
 data element. This follows from our recent facilitated conversations and plenary discussions concerning the need to better define the values in a such a data element.
<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt;line-height:16.2pt"> <u></u><u></u></p>
<ol start="1" type="1">
<li class="MsoNormal">
There appears to be momentum to support a standardized data element that MAY be used by Registrars if they choose to differentiate between legal and natural persons, and/or whether a registration data set contains personal data. That said, based on recent input
 and discussion, moving this forward to a consensus recommendation appears likely only if the full group agrees that any disclosures or use of the data element(s) would occur within a restricted system such as SSAD.<u></u><u></u></li></ol>
<p class="MsoNormal"> <u></u><u></u></p>
<ol start="2" type="1">
<li class="MsoNormal">
It has also been suggested that the KIND data element within RDAP, which already exists, could be modified to become fit for purpose. Whether it is or not, additional specificity is required on how the data element(s) will achieve the purpose of our policy objective.
 Without that specificity, the benefit of Recommendation #3 may be difficult to define or implement.<u></u><u></u></li></ol>
<p> <u></u><u></u></p>
<ol start="3" type="1">
<li class="MsoNormal">
Doing this extra work now depends in part on whether we can reach consensus around the development/use of a standardized data element within a restricted system such as SSAD, so that may be a gating question to be answered in short order.<u></u><u></u></li></ol>
<p class="MsoNormal"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt;line-height:16.2pt"><b><u>Assignment:</u></b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt;line-height:16.2pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt;line-height:16.2pt">If there is general agreement among the full team that a standardized data element would be used within a restricted system, the small team will develop a proposal that can better inform Recommendation
 #3 and, if adopted, better inform the parties who would implement it. As such, for the purpose of this very focused work, the topics of transfer of the data element from Registrar to Registry and the publication of data element(s) to a public directory are
 out of scope. If there’s general agreement to proceed, the proposed specific tasks of the small group are:<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt;line-height:16.2pt"> <u></u><u></u></p>
<div style="margin-left:27pt">
<p class="MsoNormal">• Is the KIND RDAP data element fit for purpose of differentiation or the indication of whether the registration data contains personal data?<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• If not, what data element(s) need to be created?<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• What are the value types for these data element(s) and its respective definition?<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• Revision of Recommendation #3 text.<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• Indication of what ICANN Org must do vs. IETF or other standards bodies.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Suggested contributors: I’d like to avoid over-engineering or restricting this small group, but it seems that input from Steve Crocker, Brian King, Volker Greimann, Marc Anderson,
 Alan Greenberg, and Chris Lewis-Evans would be a great starting point to develop text for full EPDP team consideration. If anyone else has a strong interest in participating, feel free to let me know during Thursday’s plenary call, but we should try to keep
 it manageable for scheduling purposes. Staff will also support the group’s work.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p style="margin:0in 0in 0.0001pt;line-height:16.2pt"><b><u>Suggested Timing:</u></b><u></u><u></u></p>
<div style="margin-left:27pt">
<p class="MsoNormal">• 20 Aug or 21 Aug – first small team meeting<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• 24 Aug – provide update to plenary<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• 24,25 Aug – additional meetings as necessary; send output to plenary<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• 26 Aug – <u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Please consider this proposal and come prepared to give initial thoughts/feedback during Thursday’s plenary. There’s some additional context included below.<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Thanks in advance!<u></u><u></u></p>
<p class="MsoNormal">Keith<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p style="margin:0in 0in 0.0001pt;line-height:16.2pt"><b><u>Appendix Contents:</u></b><u></u><u></u></p>
<div style="margin-left:27pt">
<p class="MsoNormal">• Brian King’s email 5 Aug 2021<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• RySG Operational Challenge comment<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal" style="margin-left:27pt">
• Steve Crocker Zoom chat comments<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p style="margin:0in 0in 0.0001pt;line-height:16.2pt"><b>Appendix:</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt;line-height:16.2pt"><b>Brian King’s email 5 Aug 2021:</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">Hi all, <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">I’d like to share some thoughts on how we could leverage the "kind" attribute in RDAP to convey legal vs. natural registrant data. <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">RDAP uses <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_rfc7095&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ZWAa2OqgTmi7qj2a3LdkCJBk2FgS_bjvOE25EF5aNqc&s=_iCyyozPy8O9rDaJOckHD1vV_7nXvvCL0aDn_2xp5ro&e=" target="_blank"><span style="color:rgb(5,99,193)">jCard</span></a> (a
 json version of the <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_rfc6350&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ZWAa2OqgTmi7qj2a3LdkCJBk2FgS_bjvOE25EF5aNqc&s=WznYXurUATL3BHkfO6vaON88WPD_ZFhqgJB87FrOlJk&e=" target="_blank"><span style="color:rgb(5,99,193)">vCard</span></a> standard)
 to convey contact information about individuals and organizations in <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_rfc7483&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ZWAa2OqgTmi7qj2a3LdkCJBk2FgS_bjvOE25EF5aNqc&s=va8Ii11hnpWYkmiaLkJl4ohY4ip9Pc6Wj2Hkvioxo1Y&e=" target="_blank"><span style="color:rgb(5,99,193)">json
 formatted RDAP Responses</span></a>.     <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">The <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_rfc6350&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ZWAa2OqgTmi7qj2a3LdkCJBk2FgS_bjvOE25EF5aNqc&s=WznYXurUATL3BHkfO6vaON88WPD_ZFhqgJB87FrOlJk&e=" target="_blank"><span style="color:rgb(5,99,193)">vCard</span></a> spec
 (and thus <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_rfc7095&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ZWAa2OqgTmi7qj2a3LdkCJBk2FgS_bjvOE25EF5aNqc&s=_iCyyozPy8O9rDaJOckHD1vV_7nXvvCL0aDn_2xp5ro&e=" target="_blank"><span style="color:rgb(5,99,193)">jCard</span></a>)
 does not mandate or require the inclusion of “kind”.   Its inclusion is optional and if it is not present the kind of “individual” is to be assumed.   From the <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_rfc6350&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ZWAa2OqgTmi7qj2a3LdkCJBk2FgS_bjvOE25EF5aNqc&s=WznYXurUATL3BHkfO6vaON88WPD_ZFhqgJB87FrOlJk&e=" target="_blank"><span style="color:rgb(5,99,193)">vCard</span></a> spec:  <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_rfc6350-23section-2D6.1.4&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ZWAa2OqgTmi7qj2a3LdkCJBk2FgS_bjvOE25EF5aNqc&s=VDvAoRZVjaPKNzio98DH4h6BYC3xG9ku7zZXUnxoJBo&e=" target="_blank"><b><span style="color:rgb(5,99,193)">6.1.4</span></b></a><b>. 
 KIND</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">   Purpose:  To specify the kind of object the vCard represents.<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">   Value type:  A single text value.<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">   Cardinality:  *1 <i>[Exactly one instance per vCard MAY be present.]</i><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">   Special notes:  The value may be one of the following:<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      <b>"individual"  for a vCard representing a single person or entity.</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>         This is the default kind of vCard.</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      "group"  for a vCard representing a group of persons or entities.<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         The group's member entities can be other vCards or other types<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         of entities, such as email addresses or web sites.  A group<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         vCard will usually contain MEMBER properties to specify the<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         members of the group, but it is not required to.  A group vCard<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         without MEMBER properties can be considered an abstract<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         grouping, or one whose members are known empirically (perhaps<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         "IETF Participants" or "Republican U.S. Senators").<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         All properties in a group vCard apply to the group as a whole,<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         and not to any particular MEMBER.  For example, an EMAIL<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         property might specify the address of a mailing list associated<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         with the group, and an IMPP property might refer to a group<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         chat room.<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      <b>"org"  for a vCard representing an organization.  An organization</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>         vCard will not (in fact, MUST NOT) contain MEMBER properties,</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>         and so these are something of a cross between "individual" and</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>         "group".  An organization is a single entity, but not a person.</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>         It might represent a business or government, a department or</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>         division within a business or government, a club, an</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>         association, or the like.</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>         All properties in an organization vCard apply to the</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>         organization as a whole, as is the case with a group vCard.</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>         For example, an EMAIL property might specify the address of a</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>         contact point for the organization.</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      "location"  for a named geographical place.  A location vCard will<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         usually contain a GEO property, but it is not required to.  A<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         location vCard without a GEO property can be considered an<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         abstract location, or one whose definition is known empirically<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         (perhaps "New England" or "The Seashore").<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         All properties in a location vCard apply to the location<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         itself, and not with any entity that might exist at that<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         location.  For example, in a vCard for an office building, an<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         ADR property might give the mailing address for the building,<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         and a TEL property might specify the telephone number of the<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         receptionist.<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      An x-name.  vCards MAY include private or experimental values for<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         KIND.  Remember that x-name values are not intended for general<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         use and are unlikely to interoperate.<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      An iana-token.  Additional values may be registered with IANA (see<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">        <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_rfc6350-23section-2D10.3.4&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ZWAa2OqgTmi7qj2a3LdkCJBk2FgS_bjvOE25EF5aNqc&s=vWjyHE5BqIxOwmSLyN32eSCpw3RFfsm4oK1mfqwYLOI&e=" target="_blank"><span style="color:rgb(5,99,193)"> Section
 10.3.4</span></a>).  A new value's specification document MUST<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         specify which properties make sense for that new kind of vCard<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         and which do not.<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      Implementations MUST support the specific string values defined<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      above.  <b>If this property is absent, "individual" MUST be assumed</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>      as the default.</b>  If this property is present but the<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      implementation does not understand its value (the value is an<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      x-name or iana-token that the implementation does not support),<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      the implementation SHOULD act in a neutral way, which usually<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      means treating the vCard as though its kind were "individual".<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      The presence of MEMBER properties MAY, however, be taken as an<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      indication that the unknown kind is an extension of "group".<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">ICANN could of course create and mandate a profile that describes how the jCard “kind” value can be used to distinguish between natural (“individual”) and legal (“org”) contacts.  <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">If we get pushback to re-using (or overloading) “individual” and “org” to indicate legal and natural, we could use the iana-token extension mechanism defined in the spec.  Essentially this would allow us to create
 two new RDAP specific “kind” values.  E.g. <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">"legal"  <We would create a definition that would detail what the kind <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">value of “legal” means><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">"natural"  <We would create a definition that would detail what the kind <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">value of “natural” means>  <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">This would be accomplished by creating an internet-id and submitting to IANA (IPT) for approval.  <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">Lastly, there is an internet-draft being worked on in the “regext” working group in the IETF.  The regext working group is where all the RDAP technical specs are defined. <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">This internet-draft, called the <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft-2Dharrison-2Dregext-2Drdap-2Djcard-2Dprofile-2D00.html&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ZWAa2OqgTmi7qj2a3LdkCJBk2FgS_bjvOE25EF5aNqc&s=AH7s959LhuGeUQguI2S2cxYVbELvkhki8FKaCuYqBGo&e=" target="_blank"><span style="color:rgb(5,99,193)">RDAP
 jCard Profile Spec</span></a>, currently requires the use of kind in all RDAP jCard responses. <u></u><u></u></p>
<div style="margin-left:27pt">
<p class="MsoNormal">o “Each jCard MUST contain a "kind" property. The value of that property MUST be "individual", "group", or "org".”<u></u><u></u></p>
</div>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">Now I don’t know the status of this draft - but it could be used as a “vehicle” to standardize any changes ICANN may need - assuming they were needed.  <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">RDAP Response snippets that use “kind = individual”<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__godaddy.com&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ZWAa2OqgTmi7qj2a3LdkCJBk2FgS_bjvOE25EF5aNqc&s=IpekxI99LmRE_mta6rPGepev0sTuawcVTFI9kuZfVVU&e=" target="_blank"><span style="color:rgb(5,99,193)">godaddy.com</span></a> example
 (registrar = GoDaddy)<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">"entities": [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      {<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         "objectClassName": "entity",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         "handle": "1",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         "vcardArray": [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">            "vcard",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">            [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "version",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  {},<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "text",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "4.0"<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               ],<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>                  "kind",</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>                  {},</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>                  "text",</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>                  "individual"</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               ],<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "org",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  {<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                     "type": "work"<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  },<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "text",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "Go Daddy Operating Company, LLC"<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               ],<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "adr",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  {},<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "text",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                     "",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                     "",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                     "",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                     "",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                     "Arizona",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                     "",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                     "United States"<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  ]<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               ]<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">            ]<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         ],<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         "roles": [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">            "registrant"<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         ],<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         "events": [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">            {<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               "eventAction": "last update",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               "eventDate": "2021-06-22T11:49:32Z"<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">            }<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         ],<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         "remarks": [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">            {<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               "title": "REDACTED FOR PRIVACY",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               "type": "object truncated due to authorization",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               "description": [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "Some of the data in this object has been removed."<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               ]<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">            }<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         ]<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      },<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__namecheap.com&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ZWAa2OqgTmi7qj2a3LdkCJBk2FgS_bjvOE25EF5aNqc&s=FSHWJZUJ53p9d6k9OgEGc8lhNOSZElpBgI8TCK2L_tM&e=" target="_blank"><span style="color:rgb(5,99,193)">namecheap.com</span></a> example
 (registrar = eNom)<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">"entities": [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      {<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         "objectClassName": "entity",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         "roles": [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">            "registrant"<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         ],<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         "vcardArray": [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">            "vcard",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">            [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "version",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  {},<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "text",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "4.0"<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               ],<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  <b>"kind",</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>                  {},</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>                  "text",</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>                  "individual"</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               ],<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "lang",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  {},<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "language-tag",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "en"<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               ],<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "adr",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  {},<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "text",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                     "",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                     "",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                     "",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                     "",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                     "AZ",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                     "",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                     "US"<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  ]<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               ],<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "contact-uri",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  {},<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "uri",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">                  "<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__tieredaccess.com_contact_ccfaafca-2Db98c-2D4a8f-2D8746-2Dbdaa321c628d&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ZWAa2OqgTmi7qj2a3LdkCJBk2FgS_bjvOE25EF5aNqc&s=sODG-xyeBvBKzfJnJHIuAIblUNvbBZ9Nfrrc9bzL5lo&e=" target="_blank"><span style="color:rgb(5,99,193)">https://tieredaccess.com/contact/ccfaafca-b98c-4a8f-8746-bdaa321c628d</span></a>"<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               ]<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">            ]<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         ],<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         "remarks": [<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">            {<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               "title": "REDACTED FOR PRIVACY",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               "description": "Some of the data in this object has been removed",<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">               "type": "object redacted due to authorization"<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">            }<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">         ]<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt">      },<u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>RySG Response on Kind Data Element:</b><u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>RDAP “kind” element</b><u></u><u></u></p>
<div style="margin-left:27pt">
<p class="MsoNormal">• The “kind” element isn’t actually an RDAP element, it’s a vcard element (which is a different standard that has been incorporated into the RDAP specification).<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• The vcard “kind” element isn’t a great fit for differentiating between data of legal and natural persons registrations. The possible values of “group, “org”, “individual” or “location”
 are not defined with GDPR or data protection in mind and leveraging them here would be a bit of a square peg/round hole.  <u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• Each RDAP response contains multiple vcard elements (not just one for the entire domain lookup). In addition to a vcard for each domain contact, the registrar specific data is
 returned as part of a vcard. The abuse contact email and abuse contact phone data are both also returned as separate vcards.<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• The vcard specification has not been a good fit for domain RDAP responses and there is an effort underway to replace vcard with a different standard (possibly jcard).<u></u><u></u></p>
</div>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"> <u></u><u></u></p>
<p style="margin:0in 0in 0.0001pt"><b>Steve Crocker from 17 Aug 2021 Zoom Chat:</b><u></u><u></u></p>
<div style="margin-left:27pt">
<p class="MsoNormal">• 01:23:43​Steve Crocker, SSAC:​If the kind data element is going to be expanded to include additional details of legal persons, the number of possibilities expands a bit.  It’s
 manageable but is a bit more than one might first think.  The possible responses to the kind question become:<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• 01:23:51​Steve Crocker, SSAC:​Natural<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• 01:24:12​Steve Crocker, SSAC:​Legal with personal data<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• 01:24:19​Steve Crocker, SSAC:​Legal without personal data<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• 01:24:36​Steve Crocker, SSAC:​Legal without specification as to whether it contains personal data<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• 01:24:50​Steve Crocker, SSAC:​Unspecified<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• 01:25:29​Steve Crocker, SSAC:​In addition to these five responses, there also has to be a way of indicating the lack of data, e.g. if the question hasn’t been asked.<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• 01:26:19​Steve Crocker, SSAC:​In practice, this might create a bit of confusion.  For example, the registrant might have a hard time distinguishing whether to answer “natural”
 vs “legal with personal”<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• 01:27:57​Steve Crocker, SSAC:​An alternative approach is to use two distinct data elements, one for Natural/Legal/Unspecific and a separate one for Personal/NoPersonal/Unspecified. 
 This approach would also be confusing to some.<u></u><u></u></p>
</div>
<div style="margin-left:27pt">
<p class="MsoNormal">• 01:27:59​Steve Crocker, SSAC:​I'M neutral as to which of these approaches is chosen.  Both will work and both will be confusing to some.  And either will be useful.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Gnso-epdp-team mailing list<br>
<a href="mailto:Gnso-epdp-team@icann.org" target="_blank">Gnso-epdp-team@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a><br>
_______________________________________________<br>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" target="_blank">https://www.icann.org/privacy/policy</a>)
 and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style
 delivery or disabling delivery altogether (e.g., for a vacation), and so on.<u></u><u></u></p>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>

</blockquote></div>