- Gnso-epdp-team - lists.icann.org

**REMINDER** Meeting Invitation | GNSO Temp Spec gTLD RD EPDP - Phase 2A call | Tuesday, 24 August 2021 at 14:00 UTC
by Julie Bisland Aug. 23, 2021

Aug. 23, 2021

Dear all, The GNSO Temp Spec gTLD RD EPDP – Phase 2A call is scheduled on Tuesday, 24 August 2021 at 14:00 UTC for 90 minutes. Zoom room information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/92181477886?pwd=TlJHTU5E…> Passcode: Z@S07?t=v5 If you are joining via audio only: One tap mobile US: +13126266799,,92181477886#,,,,,,0#,,3121016458# or +13462487799,,92181477886#,,,,,,0#,,3121016458# Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acVxz9PmJI [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acVxz9PmJI__;!!PtGJab4!u…> Members, alternates, observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/IgMuCg * Check your time zone: https://tinyurl.com/m4m2u6vf [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/m4m2u6vf__;!!PtGJab4!oOSYLaF…> ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_a_ican…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the EPDP Team is aware at any time who is active. Alternate Assignment – EPDP Phase 2A wiki page<https://community.icann.org/x/h4jzC>. * Members (and alternates replacing members), please select Panelists and Attendees, or Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates not replacing a member: Please rename your line by adding THREE Zs - (zzz) before your name and add, in parentheses at the end, (your affiliation - alternate). To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat (apart from private chats) or use any of the other zoom room functionalities such as raising hands or agreeing / disagreeing. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

Proposed Small Team on Rec #3 and Standardized Data Element Values
by Drazek, Keith Aug. 19, 2021

Aug. 19, 2021

Hi all, 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. 1. 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. 2. 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. 3. 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. Assignment: 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: • Is the KIND RDAP data element fit for purpose of differentiation or the indication of whether the registration data contains personal data? • If not, what data element(s) need to be created? • What are the value types for these data element(s) and its respective definition? • Revision of Recommendation #3 text. • Indication of what ICANN Org must do vs. IETF or other standards bodies. 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. Suggested Timing: • 20 Aug or 21 Aug – first small team meeting • 24 Aug – provide update to plenary • 24,25 Aug – additional meetings as necessary; send output to plenary • 26 Aug – Please consider this proposal and come prepared to give initial thoughts/feedback during Thursday’s plenary. There’s some additional context included below. Thanks in advance! Keith Appendix Contents: • Brian King’s email 5 Aug 2021 • RySG Operational Challenge comment • Steve Crocker Zoom chat comments Appendix: Brian King’s email 5 Aug 2021: Hi all, I’d like to share some thoughts on how we could leverage the "kind" attribute in RDAP to convey legal vs. natural registrant data. RDAP uses jCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_d…> (a json version of the vCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_d…> standard) to convey contact information about individuals and organizations in json formatted RDAP Responses<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_d…>. The vCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_d…> spec (and thus jCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_d…>) 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 vCard<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_d…> spec: 6.1.4<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_d…>. KIND Purpose: To specify the kind of object the vCard represents. Value type: A single text value. Cardinality: *1 [Exactly one instance per vCard MAY be present.] Special notes: The value may be one of the following: "individual" for a vCard representing a single person or entity. This is the default kind of vCard. "group" for a vCard representing a group of persons or entities. The group's member entities can be other vCards or other types of entities, such as email addresses or web sites. A group vCard will usually contain MEMBER properties to specify the members of the group, but it is not required to. A group vCard without MEMBER properties can be considered an abstract grouping, or one whose members are known empirically (perhaps "IETF Participants" or "Republican U.S. Senators"). All properties in a group vCard apply to the group as a whole, and not to any particular MEMBER. For example, an EMAIL property might specify the address of a mailing list associated with the group, and an IMPP property might refer to a group chat room. "org" for a vCard representing an organization. An organization vCard will not (in fact, MUST NOT) contain MEMBER properties, and so these are something of a cross between "individual" and "group". An organization is a single entity, but not a person. It might represent a business or government, a department or division within a business or government, a club, an association, or the like. All properties in an organization vCard apply to the organization as a whole, as is the case with a group vCard. For example, an EMAIL property might specify the address of a contact point for the organization. "location" for a named geographical place. A location vCard will usually contain a GEO property, but it is not required to. A location vCard without a GEO property can be considered an abstract location, or one whose definition is known empirically (perhaps "New England" or "The Seashore"). All properties in a location vCard apply to the location itself, and not with any entity that might exist at that location. For example, in a vCard for an office building, an ADR property might give the mailing address for the building, and a TEL property might specify the telephone number of the receptionist. An x-name. vCards MAY include private or experimental values for KIND. Remember that x-name values are not intended for general use and are unlikely to interoperate. An iana-token. Additional values may be registered with IANA (see Section 10.3.4<https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_d…>). A new value's specification document MUST specify which properties make sense for that new kind of vCard and which do not. Implementations MUST support the specific string values defined above. If this property is absent, "individual" MUST be assumed as the default. If this property is present but the implementation does not understand its value (the value is an x-name or iana-token that the implementation does not support), the implementation SHOULD act in a neutral way, which usually means treating the vCard as though its kind were "individual". The presence of MEMBER properties MAY, however, be taken as an indication that the unknown kind is an extension of "group". 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. 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. "legal" <We would create a definition that would detail what the kind value of “legal” means> "natural" <We would create a definition that would detail what the kind value of “natural” means> This would be accomplished by creating an internet-id and submitting to IANA (IPT) for approval. 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. This internet-draft, called the RDAP jCard Profile Spec<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draf…>, currently requires the use of kind in all RDAP jCard responses. o “Each jCard MUST contain a "kind" property. The value of that property MUST be "individual", "group", or "org".” 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. RDAP Response snippets that use “kind = individual” godaddy.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__godaddy.com&d=DwMGaQ&c=…> example (registrar = GoDaddy) "entities": [ { "objectClassName": "entity", "handle": "1", "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "kind", {}, "text", "individual" ], [ "org", { "type": "work" }, "text", "Go Daddy Operating Company, LLC" ], [ "adr", {}, "text", [ "", "", "", "", "Arizona", "", "United States" ] ] ] ], "roles": [ "registrant" ], "events": [ { "eventAction": "last update", "eventDate": "2021-06-22T11:49:32Z" } ], "remarks": [ { "title": "REDACTED FOR PRIVACY", "type": "object truncated due to authorization", "description": [ "Some of the data in this object has been removed." ] } ] }, namecheap.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__namecheap.com&d=DwMGaQ&…> example (registrar = eNom) "entities": [ { "objectClassName": "entity", "roles": [ "registrant" ], "vcardArray": [ "vcard", [ [ "version", {}, "text", "4.0" ], [ "kind", {}, "text", "individual" ], [ "lang", {}, "language-tag", "en" ], [ "adr", {}, "text", [ "", "", "", "", "AZ", "", "US" ] ], [ "contact-uri", {}, "uri", "https://tieredaccess.com/contact/ccfaafca-b98c-4a8f-8746-bdaa321c628d<https://urldefense.proofpoint.com/v2/url?u=https-3A__tieredaccess.com_conta…>" ] ] ], "remarks": [ { "title": "REDACTED FOR PRIVACY", "description": "Some of the data in this object has been removed", "type": "object redacted due to authorization" } ] }, RySG Response on Kind Data Element: RDAP “kind” element • 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). • 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. • 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. • 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). Steve Crocker from 17 Aug 2021 Zoom Chat: • 01:23:43Steve 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: • 01:23:51Steve Crocker, SSAC:Natural • 01:24:12Steve Crocker, SSAC:Legal with personal data • 01:24:19Steve Crocker, SSAC:Legal without personal data • 01:24:36Steve Crocker, SSAC:Legal without specification as to whether it contains personal data • 01:24:50Steve Crocker, SSAC:Unspecified • 01:25:29Steve 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. • 01:26:19Steve 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” • 01:27:57Steve 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. • 01:27:59Steve 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.

4 9

Notes and action items - EPDP Phase 2A Meeting #37 - 19 August 2021
by Caitlin Tubergen Aug. 19, 2021

Aug. 19, 2021

Dear EPDP Team, Please find below the notes and action items from today’s meeting. The EPDP Phase 2A Meeting will be Tuesday, 24 August at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- Action Items 1. Data element small team representatives to respond to Doodle Poll ASAP, noting that the small team's update to the plenary is scheduled for Tuesday, 24 August. 2. Leadership and Support Staff to update the language of Recommendation 4 and New Recommendation by COB Friday, 20 August based on today's discussion. 3. As no disagreement was received during today's call, Support Staff to add RySG proposed language into Draft Recommendation 5<https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#h…> (email contacts) and EPDP Team members to provide proposed edits (if any) by COB, Monday, 23 August. 4. Amr to propose updates to Recommendation 1<https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#h…> by COB Monday, August 23. EPDP Phase 2A - Meeting #37 Proposed Agenda Thursday 19 August 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) a. Small team to develop proposal for values of the data element (if agreed to) - Please see email sent yesterday. Believe there is value for a small group to review the values for a standardized data element. - CPH has signaled a willingness to support a standardized data element so long as it is optional, and the display of the data element would be within a closed system such as the SSAD. The question is – regarding the establishment of a new data element – is this worth doing, and for the members who preferred a mandatory use of a field, whether a standardized data element that is optional and used in an SSAD-like system would get consensus support. - The list of assigned volunteers are members who previously opined on this issue and could return to the full group in very short order. EPDP Team response: - Regarding the usage of the data element – if this is restricted to SSAD or similar tools, what does this mean? If a registrar is using this data element, but receives a request outside SSAD, would it not be used? - The registrar is question could still use it, but the question is how the flag is used and how data will be provided in response to a request. The thinking is that the standardized data element could be useful for everyone as we look to develop more automated tools, such as the SSAD. The flagging capability could be used down the road. - The IPC would want the possibility for the data element to be mandatory, so the question about gating it is an odd question. At a minimum, the contracted party should have the capacity to publish it, even if it is voluntary. - The Team seems to be in broad agreement that this should exist. The data element should exist – the wording used suggested that it would only be visible in SSAD. The main point – by having this piece of data, it is available in a restricted context – this would not preclude the registrar from displaying it publicly (if they so choose) or using it for their own purposes. - Important to identity SSAD or comparable tools as a possible or likely use of the element. The SSAD is many years away – do not want to delay the use of the element until SSAD. Do not confuse the discussion with the uses, and the impact/use may change over time. - What does the use of the standardized data element trigger in terms of output of registrant data. Team should be careful not to conflate this. When we discuss the use of a flag or the display, is it the flag we are discussing or the output that comes in response to the flag? - Recommend a permissive policy recommendation – no need to restrict, since this is optional. A Rr may use the data element (or not); the policy should not restrict how the element is used. - The interventions heard seem to argue for a broader scope than what was laid out in Keith’s email. CPs do not all agree that this data element should exist – there is not broad agreement. CPs are trying to come up with something that we can get our stakeholder group to get behind and support. Working toward the minimum that CPs could support. - Our policy recommendation should not restrict anything. 3. Continue review and updates to section 3 of Final Report - Responses to Council Questions & Recommendations (75 minutes) – see https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#<https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit> As a reminder: proposed timeline to get to Final Report 19 August – consider suggestions for further consideration & agree on updates to report 24 & 26 August – consider suggestions for further consideration & agree on updates to report 27 August – publish draft Final Report for EPDP Team review, consensus call. 30 August – deadline for minority statements 31 August – finalize report and address any outstanding items, if any. a. Review of Recommendation #4 · Consider input provided * There are two updates made based on the prior discussion. Some noted that it should specify that legal person data is not protected. The suggested language over the list was added to the table in the document. * Which of the three versions provided should be included in the report? * The second part of the conversation – a new recommendation based on the outcome of the mediated conversations deals with a code of conduct as a way to get further certainty around GDPR standard. Tried to reflect IPC’s comment regarding additional participants in this recommendation. · EPDP Team discussion * From a CPH perspective – do not agree to include other parties in the development of a Code of Conduct. From a CPH perspective, this would be akin to including other parties in a contract discussion. * Code of conduct has a specific terminology, which makes it akin to a contractual negotiation. Could agree to a code of conduct, but only b/w the RrSG and the code of conduct as per the RAA. * If only CPs can participate in discussions, which would ultimately find its way into a contract, is tantamount to saying – there can never be consensus policy. * Did not envision a Code of Conduct getting down to escrow agents and EBERO providers. Contracts state that CPs have to participate in consensus policy process and abide by those consensus policies. * No matter what this group recommends, the EPDB will want to know that processors are consulted. With that in mind, would like to include that language here. * There is a specific reference to codes of conducts in the RA and there is some confusion whether the group is talking about a code of conduct in the RA vs. the Code of Conduct under the GDPR and previous directive. There is confusion and conflation of these terms, and it is important to be clear about this. * The code of conduct discussion should not be another phase of EPDP. This group has discussed a code of conduct numerous times over the last few years. The EPDP Team is charged with coming up with policy recommendations, and from there – the EPDP’s mandate is completed. The Code of Conduct negotiations should occur elsewhere. The discussion should take place with groups who are affected by it. Since we are still waiting for the DPAs from Phase 1, it is difficult to say who needs to be at the table. Controllers definitely need to be at the table; processors may also need to be at the table. If entities would be sanctioned by the code of conduct, they definitely need to be at the table. Article 14, Section 4 requires the Code of Conduct must have a mechanism to control whether the Code of Conduct is being abided by. * Have discussed Codes of Conduct for third parties in Phase 2, and CPs were part of that discussion – do not see how this is different from asking to be included in the CPs’ code of conduct. * This recommendation was not proposed just for the legal v. natural distinction. Once the PDP ends and the DPAs are complete regarding who controllers and processors are, a code of conduct could be developed and submitted to the EDPB under Art. 40 of the GDPR as confirmation that what is being done is in fact in line with the GDPR so there would be legal assurances that this is compliant. It would be helpful to capture in writing how we the data is being processed. * One of the key players here is the registrant – how do we propose to involve representatives of the registrant * Staff Support will work with leadership will rework the language based on this discussion. · Confirm next steps b. Review of recommendation #5 · Consider input provided * There is proposed language from the RySG – ALAC provided one comment in response to this and asked for the B&B summary table to add. · EPDP Team discussion * The chart does not help – it is already covered in a descriptive way in bullet 3 * Intentionally omitted the discussion about automated disclosure assumes a number of things such as built in verification and validation – and seems more relevant to SSAD disclosure rather than RDDS disclosure * Seems everyone agrees to include the registry language in the table for the second reading · Confirm next steps c. Review of recommendation #1 (second reading) · Consider additional input provided * During the last discussion, there was concern over the last sentence. The proposal is to remove the sentence and retain the first sentence, not as a recommendation but as an answer to the Council’s question. * Should say recommendation part 1. The GNSO statement of the team’s task should have been worded that way. * Need to address 17.3 – advocating for the language suggested in the BC comment – group could not resolve the legal v. natural distinction. * Do not think this should be limited to 17.1. Agree with leadership’s proposal. * Support leadership language. Struck by opacity – if we cannot agree on language that everyone likes, we reduce it to a simple statement – where do we address the discussion in the report? * Could include a reference – for those who are interested in more context, please review the Initial Report as well as minority statements where groups elaborated on their views on this topic. * The reason why leaving language as it is currently is problematic is because it implies that there was consensus on 17.1, and that is not correct. * The proposed revision seems to indicate that additional work is needed – how do we go about getting a resolution to this? If 17.1 is not agreed to, should we say we failed to reach consensus for changes, therefore – 17.1 should be repealed? How can this be resolved? * Not advocating for more EPDP, but would end up with the same scenario (optional differentiation) – could clarify that no additional work is suggested at this point. * Ultimately, agree that the substance of the change is indeed in 17.1 – if we want to refer specifically to what we have been doing, we could lay this out clearly. 17.1 is the substance that the EPDP Team failed to reach consensus on; 17.2 is part of the input that was considered; 17.3 is the process used, though this was deferred to Phase 2A (instead of Phase 2). * All that is being discussed is to ensure the language reflects the process that has gone on and the level of dissatisfaction with how the process has worked. Would like to make sure that someone who cares enough to read this afterward does not come away with an incorrect understanding. * Action: Amr to include draft text in the table. · Consider leadership path forward · Confirm next steps d. Review of recommendation #2 (second reading) · Consider additional input provided * There is a slight tweak to the second paragraph in an effort to recognize the members would like to use existing processes and also scoping possible work due to legislative developments. · Consider leadership path forward * NIS2 is still a draft directive, and this is outside the scope of this EPDP. This is bad form to suggest this to the GNSO Council. The GNSO does not need to do this – councilors representing certain groups can go ahead and request a preliminary issues report so a PDP could progress without this recommendation. Do not see why this is necessary and it is not a good precedent. * From a Staff perspective, welcome the scoping teams to determine if policy work is needed rather than going to the preliminary issues report. * This recommendation was part of the mediated conversations. · Confirm next steps e. Confirm next steps 4. Wrap and confirm next EPDP Team meeting (5 minutes): a. EPDP Team Meeting #38 Tuesday 24 August at 14.00 UTC b. Confirm action items - Small Team volunteers please respond to the Doodle Poll ASAP. c. Confirm questions for ICANN Org, if any

1 0

Meeting Invitation | GNSO Temp Spec gTLD RD EPDP - Phase 2A call | Tuesday, 24 August 2021 at 14:00 UTC
by Julie Bisland Aug. 19, 2021

Aug. 19, 2021

Dear all, The GNSO Temp Spec gTLD RD EPDP – Phase 2A call is scheduled on Tuesday, 24 August 2021 at 14:00 UTC for 90 minutes. Zoom room information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/92181477886?pwd=TlJHTU5E…> Passcode: Z@S07?t=v5 If you are joining via audio only: One tap mobile US: +13126266799,,92181477886#,,,,,,0#,,3121016458# or +13462487799,,92181477886#,,,,,,0#,,3121016458# Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acVxz9PmJI [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acVxz9PmJI__;!!PtGJab4!u…> Members, alternates, observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/IgMuCg * Check your time zone: https://tinyurl.com/m4m2u6vf ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_a_ican…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the EPDP Team is aware at any time who is active. Alternate Assignment – EPDP Phase 2A wiki page<https://community.icann.org/x/h4jzC>. * Members (and alternates replacing members), please select Panelists and Attendees, or Everyone, when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates not replacing a member: Please rename your line by adding THREE Zs - (zzz) before your name and add, in parentheses at the end, (your affiliation - alternate). To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat (apart from private chats) or use any of the other zoom room functionalities such as raising hands or agreeing / disagreeing. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2A | Thursday, 19 August 2021 at 14:00 UTC
by Julie Bisland Aug. 19, 2021

Aug. 19, 2021

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2A call held on Thursday, 19 August 2021 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/5IMZCg> and the GNSO Master calendar [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call as a panelist, observers can join as an attendee to listen. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-team/> and the main wiki page<https://community.icann.org/x/IYEpBQ>. Thank you. With kind regards, Julie

1 0

**15-minute reminder** Meeting Invitation | GNSO Temp Spec gTLD RD EPDP - Phase 2A call | Thursday, 19 August 2021 at 14:00 UTC
by Julie Bisland Aug. 19, 2021

Aug. 19, 2021

**15-minute reminder** Dear all, The GNSO Temp Spec gTLD RD EPDP – Phase 2A call is scheduled on Thursday, 19 August 2021 at 14:00 UTC for 90 minutes. Zoom room information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/92181477886?pwd=TlJHTU5E…> Passcode: Z@S07?t=v5 If you are joining via audio only: One tap mobile US: +13126266799,,92181477886#,,,,,,0#,,3121016458# or +13462487799,,92181477886#,,,,,,0#,,3121016458# Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acVxz9PmJI [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acVxz9PmJI__;!!PtGJab4!u…> Members, alternates, observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/5IMZCg * Check your time zone: https://tinyurl.com/4596rx3d [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/4596rx3d__;!!PtGJab4!rsxf6zm…> ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_a_ican…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the EPDP Team is aware at any time who is active. Alternate Assignment – EPDP Phase 2A wiki page<https://community.icann.org/x/h4jzC>. * Members (and alternates replacing members), please select Panelists and Attendees when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates not replacing a member: Please rename your line by adding THREE Zs - (zzz)’before your name and add, in parentheses at the end, (your affiliation - alternate). To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat (apart from private chats) or use any of the other zoom room functionalities such as raising hands or agreeing / disagreeing. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Terri

1 0

Proposed Agenda - EPDP Team Meeting #37 on Thursday 18 August at 14.00 UTC
by Marika Konings Aug. 18, 2021

Aug. 18, 2021

Dear EPDP Team, Please find below the proposed agenda for the next meeting of the EPDP Team which has been scheduled for Thursday 18 August at 14.00 UTC. Note that we’ll be adding shortly a couple of leadership proposed updates to some of the recommendations that aim to reflect the comments and discussions to date. These will be further introduced and considered during tomorrow’s meeting. Best regards, Caitlin, Berry and Marika EPDP Phase 2A - Meeting #37 Proposed Agenda Thursday 19 August 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) * Small team to develop proposal for values of the data element (if agreed to) 3. Continue review and updates to section 3 of Final Report - Responses to Council Questions & Recommendations (75 minutes) – see https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#<https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit> As a reminder: proposed timeline to get to Final Report 19 August – consider suggestions for further consideration & agree on updates to report 24 & 26 August – consider suggestions for further consideration & agree on updates to report 27 August – publish draft Final Report for EPDP Team review, consensus call. 30 August – deadline for minority statements 31 August – finalize report and address any outstanding items, if any. * Review of Recommendation #4 · Consider input provided · EPDP Team discussion · Confirm next steps * Review of recommendation #5 · Consider input provided · EPDP Team discussion · Confirm next steps * Review of recommendation #1 (second reading) · Consider additional input provided · Consider leadership path forward · Confirm next steps * Review of recommendation #2 (second reading) · Consider additional input provided · Consider leadership path forward · Confirm next steps * Confirm next steps 4. Wrap and confirm next EPDP Team meeting (5 minutes): a. EPDP Team Meeting #38 Tuesday 24 August at 14.00 UTC b. Confirm action items c. Confirm questions for ICANN Org, if any

1 0

**REMINDER** Meeting Invitation | GNSO Temp Spec gTLD RD EPDP - Phase 2A call | Thursday, 19 August 2021 at 14:00 UTC
by Julie Bisland Aug. 18, 2021

Aug. 18, 2021

Dear all, The GNSO Temp Spec gTLD RD EPDP – Phase 2A call is scheduled on Thursday, 19 August 2021 at 14:00 UTC for 90 minutes. Zoom room information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/92181477886?pwd=TlJHTU5E…> Passcode: Z@S07?t=v5 If you are joining via audio only: One tap mobile US: +13126266799,,92181477886#,,,,,,0#,,3121016458# or +13462487799,,92181477886#,,,,,,0#,,3121016458# Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acVxz9PmJI [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acVxz9PmJI__;!!PtGJab4!u…> Members, alternates, observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only * Please be sure you have read the ICANN Expected Standards of Behavior [icann.org]<https://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Visit the Wiki agenda page: https://community.icann.org/x/5IMZCg * Check your time zone: https://tinyurl.com/4596rx3d [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/4596rx3d__;!!PtGJab4!rsxf6zm…> ONLY for Members and Alternates * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_a_ican…> to communicate who the alternate is replacing and for which period. This information will be publicly posted so that the EPDP Team is aware at any time who is active. Alternate Assignment – EPDP Phase 2A wiki page<https://community.icann.org/x/h4jzC>. * Members (and alternates replacing members), please select Panelists and Attendees when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates not replacing a member: Please rename your line by adding THREE Zs - (zzz)’before your name and add, in parentheses at the end, (your affiliation - alternate). To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat (apart from private chats) or use any of the other zoom room functionalities such as raising hands or agreeing / disagreeing. Only for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Terri

1 0

Notes and action items - EPDP Phase 2A Meeting #36 - 17 August 2021
by Caitlin Tubergen Aug. 17, 2021

Aug. 17, 2021

Dear EPDP Team, Please find below the notes and action items from today’s meeting. The next meeting will be Thursday, 19 August at 14:00 UTC. Best regards, Marika, Berry, and Caitlin -- Action Items<https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8Ad…> 1. Further to today's conversation, if groups have follow-up questions based on the benefits or operational changes discussed, please populate them into the new column in the Google Doc<https://docs.google.com/document/d/1L-SdgAb0tJlGJoBbuRWHuKSuZRIdXnia/edit>. 2. EPDP Team to review Recommendation 3-5 in Section 3 of the Draft Final Report<https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit> and provide proposed language in response to today's discussion by COB today, Tuesday, 17 August. Specifically, * With respect to Recommendation 3 (new data element), please review the RySG proposed language and the IPC proposed language and provide suggested edits with a view toward a compromise approach. * With respect to Recommendation 4 (code of conduct), please review IPC's concern and consider Art. 40 of the GDPR - how much flexibility has been applied by the EDPB to those that have developed codes of conduct to date? For example, are those that not controllers allowed to be part of the conversation? * With respect to Recommendation 5 (registrant and registration-based contacts), please review the RySG text. Are any edits required, or does the EPDP Team agree to the proposed update? EPDP Phase 2A - Meeting #36 Proposed Agenda Tuesday 17 August 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 3. Consider benefits and operational challenges identified – see https://docs.google.com/document/d/1L-SdgAb0tJlGJoBbuRWHuKSuZRIdXnia/edit (15 minutes) a. Consider following questions: · Are there any clarifying questions that anyone has about the input provided by others? · If this input has not helped create a better understanding of each other’s position, what else can be done / should be considered? · If/how should this input be captured in the Final Report or should groups be encouraged to highlight their views in their minority statements? EPDP Feedback: * This group lives within a larger environment, which is the broader internet. The idea of deciding on a data element that specifies legal/natural is out of the scope for this process. This data element exists – whether or not it is used is within the scope; however, deciding if this data element should exist in the world is outside the scope of the GNSO. The Team should assume it exists for the purposes of this conversation. * In terms of its existence, is this a reference to the kind element in RDAP, or something else? * Yes, thinking of the kind element. What we do not have and would benefit from is an organized visible data dictionary preferably maintained at the IANA registry system. Should assume the data element exists – the question should be should it be used and how. * Disagree with this characterization – ICANN org has made this clear that if this is to become a requirement, the EPDP Team must be really clear that it has to exist. If this element could be potentially referenced, the Team has to make clear what the name is and what the structure is. * If any TLD operator or address registry operator would like to make use of the data element, they can and should. In terms of ICANN org response, they will not require that data element to be substantiated in contract unless this group makes a policy recommendation. This is an IETF level question, not under the control of this group. * If the Team does not specify this data element in the data specification those who choose to use it will not use it consistently. * The IETF already did this in the RDAP work that created the “kind” element. Can the group come up with the policy that will be used with respect to the “kind” element? * What the group is asking is do we need to have a common data element or not – this is the question being asked. * The discussions this team is having are taking place in a broader context, and even if we recommend the creation of something new, this would have implications elsewhere and could trigger work in other parts of the community, including the IETF. What the team needs to focus on: is there a recommendation for new consensus policy to the GNSO Council for registrars who choose to differentiate, and if so, how? * In terms of the benefits – the benefit of the flag – GAC colleagues noted the discussion of the overall benefit of differentiation. The Team may be too late to discuss this properly. Do not think the Team has properly discussed some of the aspects here. * Struggled with not all of the responses seem to be answering the same question – for example, some of the benefits seem to be defining benefits for why differentiation should exist for all registrations, while some of the responses seem to be answering the question for a standardized data element for registrars who choose to differentiate. Some argue this should be a public data element in the RDDS. It was not always clear what the responses were referring to. It’s important to be clear what we are talking about. * The Team is discussing the benefits of a common data element that would be able to flag whether this is a legal or a natural person. The question the team should focus on is should this data element exist for registrars who choose to differentiate. * There are a number of benefits listed here – perhaps start with the benefit of the public (RDDS query) to have a consistent indication of whether the data contains legal person or natural person data. To have this be available consistently would be helpful for a number of reasons including whether to submit a one-off request for the data and to understand the likelihood that the data will be provided. Having that element publicly available would convey helpful information to users of RDDS. * The Team has been discussing benefits and many groups believe they have put forward benefits and have been repeatedly told the input was unhelpful or anecdotal. * Real example – if there is a field defined, as a consumer, if one were to go – this is not filled in, then one could choose not to do business. Suppliers in Europe are required to post information on websites. The knowledge that someone has chosen not to fill in this field and not to convey it speaks volumes. The Team has talked a lot about anecdotal evidence, but the rationales on both parties’ sides are not supportable by hard evidence. We have asked CPs to show evidence of harm and fines – if you provide education and allow correction, there are essentially no risks. * The purpose of this exercise, coming out of the facilitated discussions, was to share additional information to create a better understanding of why having a common data element would be beneficial. If nothing has triggered new discussions or ideas, perhaps the team needs to move on. * Another benefit is that once a record has been returned as no personal data in this SSAD, this could be helpful in implementing the SSAD * In terms of the ALAC input, finding it difficult to understand – specifically, there are points on consistent labelling and display (input 2 and 3) – in the absence of a data element, how is the data still not consistently labelled and displayed? CL&D is a requirement one way or another – not sure how this adds. If a flag were to be added, it would have to be consistently labelled and displayed. Encouraged to hear a flag that specifically addresses personal and non-personal data – could be included in the guidance but not required. A flag of that nature rather than a flag on registrant type would have much more utility – specifically in references to Phase 2 Rec. 9.4.4. Not sure understand input #5 – GDPR does not require differentiation b/w legal and natural persons. * Need further clarification on the kind element feedback. In terms of v-card and j-card that is being used in the RDAP – if it is going to be replaced, this seems like the opportunity to do this. Concerned about how we use the IETF in relation to policy development. Homework to capture those technical questions. * In terms of a flag, this was in reference to a common data element, and would need to specify the values that this element would take. There are future laws and regulations underway that could make this mandatory. * The Team needs to focus on text for inclusion in the Final Report. It is necessary at this point to put forward specific text. b. Confirm next steps 4. Continue review and updates to section 3 of Final Report - Responses to Council Questions & Recommendations (60 minutes) – see https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#<https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit> As a reminder: proposed timeline to get to Final Report 17 & 19 August – delivery of action items mediated conversations, consider suggestions for further consideration & agree on updates to report 24 & 26 August – consider suggestions for further consideration & agree on updates to report 27 August – publish draft Final Report for EPDP Team review, consensus call. 30 August – deadline for minority statements 31 August – finalize report and address any outstanding items, if any. a. Continue review of Recommendation #3 (if proposed language has been put forward by RySG) · Consider input provided - First issue – should this be used for SSAD, separate issue – MUST or SHOULD · EPDP Team discussion * Groups have been told what is in and out of scope – bring the SSAD into the discussion now is a red herring. This hasn’t yet been approved by the Board and may never be. The Team should not spend time discussing this any further. It does not serve the Team to discuss multiple questions simultaneously – they should be addressed orthogonally in a single context. * If you are rejecting the SSAD discussion, where would or should this discussion take place? * It should not be a huge surprise what the CPH is suggesting as it is consistent with statements made previously. The language used here is based on the proposed Rec #4.3. Registries have said previously that they are opposed to having a standardized data element in the public RDDS, but do see utility and usefulness in having that data element be available in SSAD integration. CPs will have an obligation to integrate with the SSAD system. Registries have also said that legal v. natural designation alone is insufficient, so that is why the personal or non-personal data is included in the draft language. * If we took out implementation and put “as part of the SSAD” if this would still be objectionable to ALAC colleagues in terms of scope. Could make a recommendation for a standardized data element. Observe that having a standardized data element that identifies the type of person and the type of data would be a useful infrastructure to have in place and would be a positive step. * Flagging that it would be useful to the SSAD is fine, but mandating that it is part of SSAD implementation is not fine. If we do not specify that this will be done, it may never – as SSAD is no guarantee. * In support of SSAD instead of as part of SSAD implementation * BC colleagues support the IPC recommendation and believe in the conditional must. * In terms of may or must, there is not support for MUST. The last sentence in the IPC proposal is a deal breaker – first, the obligation that registries must store the contents of this field is problematic for registries and second, do not support including this in the public RDDS response. * CPH seems happy with the data element as part of the SSAD, but where it goes to public RDDS system – even with checks and balances – where does that risk push the opponents over? Do not understand if all points are included, why can’t this data be in the public RDDS? * Having the data available when you know who the requestor is more palatable than of having it in a public database where you do not know who the requestor is. Where CPs can get on board is the SSAD where you know who the requestor is and have some assurances of how that data would be used. * In terms of having the flag for legal persons – not talking about having a flag just for legal persons – we are talking about flagging the data for all responses. From Ry perspective, not just talking about data of legal persons – this is additional information about all types of registrants. * Have talked about having the field be empty, but the lack of information is useful in its own right. * Not talking about the data of natural persons, just legal persons. * 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” – think about this like you are filling out a multiple choice form – decline to declare vs. just leaving it blank – these are not the same, and the inferences drawn from the two answers are not the same. * If this is blank outside of the SSAD, what does this tell others about the nature of the data? Not having data in that flag or field could tell you something. * There are six distinct possibilities – no answer given, unspecified as to legal vs. natural, unspecified where legal person has not indicated personal or not personal – the responses have started to proliferate * As a registrar, it’s more important to know whether there is personal information rather than knowing what kind of registrant the person is. * Agree that in an ideal world the two meanings proposed – “not provided” or “not asked” have very different meanings and while it would be preferable to have both options – at this point, it’s unlikely to get agreement in this EPDP – would prefer to have an element that is not filled in. * If there are implications, need to be aware of them – for example, the kind element. * “In support of the SSAD, a standardized data element should be identified that would indicate the type of person it concerns (natural or legal) and if legal, also the type of data it concerns (personal or non-personal data). Such a data element could be used by registrars who choose to differentiate between legal and natural persons. Such flagging could facilitate review of disclosure requests via SSAD.” * Support of this language · Confirm next steps * Review of Recommendation #4 · Consider input provided · EPDP Team discussion · Confirm next steps * Review of recommendation #5 (if proposed language has been put forward) · Consider input provided · EPDP Team discussion · Confirm next steps * Confirm next steps 5. Wrap and confirm next EPDP Team meeting (5 minutes): a. EPDP Team Meeting #37 Thursday 19 August at 14.00 UTC b. Confirm action items c. Confirm questions for ICANN Org, if any

1 0

Post Call | GNSO Temp Spec gTLD RD EPDP – Phase 2A | Tuesday, 17 August 2021 at 14:00 UTC
by Terri Agnew Aug. 17, 2021

Aug. 17, 2021

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2A call held on Tuesday, 17 August 2021 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/HQMuCg> and the GNSO Master calendar [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call as a panelist, observers can join as an attendee to listen. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-epdp-team/> and the main wiki page<https://community.icann.org/x/IYEpBQ>. Thank you. With kind regards, Terri

1 0