August 2021 - Gnso-epdp-team

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

Aug. 24, 2021

Dear all, All recordings for the GNSO Temp Spec gTLD RD EPDP – Phase 2A call held on Tuesday, 24 August 2021 at 14:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/IgMuCg> 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

Meeting Invitation | GNSO Temp Spec gTLD RD EPDP - Phase 2A call | Thursday, 26 August 2021 at 14:00 UTC
by Terri Agnew Aug. 24, 2021

Aug. 24, 2021

Dear all, The GNSO Temp Spec gTLD RD EPDP – Phase 2A call is scheduled on Thursday, 26 August 2021 at 14:00 UTC for 90 minutes. Zoom room information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 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/54MZCg * Check your time zone: https://tinyurl.com/32r8stx7 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, Terri

1 0

**Starting in 13 minutes | Meeting Invitation | GNSO Temp Spec gTLD RD EPDP - Phase 2A call | Tuesday, 24 August 2021 at 14:00 UTC
by Terri Agnew Aug. 24, 2021

Aug. 24, 2021

**Starting in 13 minutes 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 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

Re: [Gnso-epdp-team] Proposed agenda - EPDP Team meeting #38 on Tuesday 24 August at 14.00 UTC
by Marika Konings Aug. 23, 2021

Aug. 23, 2021

Please note that thanks to the efforts of the small team, proposed updated language has now been included in the google doc for recommendation #3 (see https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#) Please review this proposed language in advance of the meeting. Best regards, Caitlin, Berry and Marika From: Gnso-epdp-team <gnso-epdp-team-bounces(a)icann.org> on behalf of Marika Konings via Gnso-epdp-team <gnso-epdp-team(a)icann.org> Reply to: Marika Konings <marika.konings(a)icann.org> Date: Monday, 23 August 2021 at 16:44 To: "gnso-epdp-team(a)icann.org" <gnso-epdp-team(a)icann.org> Subject: [Gnso-epdp-team] Proposed agenda - EPDP Team meeting #38 on Tuesday 24 August at 14.00 UTC Dear EPDP Team, Please find below the proposed agenda for the next meeting of the EPDP Team which is scheduled for Tuesday 24 August at 14.00 UTC. You are encouraged to provide any further input you have on any of the recommendations, apart from #3 which is being worked on by the sub-team, by COB today, Monday. As discussed on the call last week, leadership has put forward proposed updates for recommendation #4 in the google doc to reflect the input that was received during the call. Best regards, Caitlin, Berry and Marika EPDP Phase 2A - Meeting #38 Proposed Agenda Tuesday 24 August 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 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: timeline to get to Final 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. * Update on status of recommendation #3 · Small team status update · Confirm next steps * Review of Recommendation #4 (second reading) · Consider input provided · EPDP Team discussion · Confirm next steps * Review of recommendation #5 (second reading) · Consider input provided · EPDP Team discussion · Confirm next steps * Review of recommendation #1 (third reading – if updated language is received) · Consider additional input provided · Consider leadership path forward · Confirm next steps * Review of recommendation #2 (third 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 #39 Thursday 26 August at 14.00 UTC b. Confirm action items c. Confirm questions for ICANN Org, if any

1 0

Action Item Re: Recommendation #1
by Amr Elsadr Aug. 23, 2021

Aug. 23, 2021

Hi, On Thursday’s meeting, I picked up the following action item: > "Amr to propose updates to Recommendation 1 <https://docs.google.com/document/d/1C2RIAEonzE3vA1cN5lep9sZl2pKEniT6/edit#h…> by COB Monday, August 23.” As discussed on Thursday, I believed that clarifying in how the different parts of Phase 1, recommendation #17 were addressed in subsequent phases might be helpful in both demonstrating the EPDP Team’s approach to dealing with the legal vs. natural issue, as well as address some concerns raised regarding how accurately the recommendation (although I do appreciate that it isn’t in fact a recommendation) addressed the EPDP Team’s conclusion on this topic. I hope that the proposed text is found to be helpful. Thanks. Amr

1 0

Proposed agenda - EPDP Team meeting #38 on Tuesday 24 August at 14.00 UTC
by Marika Konings Aug. 23, 2021

Aug. 23, 2021

Dear EPDP Team, Please find below the proposed agenda for the next meeting of the EPDP Team which is scheduled for Tuesday 24 August at 14.00 UTC. You are encouraged to provide any further input you have on any of the recommendations, apart from #3 which is being worked on by the sub-team, by COB today, Monday. As discussed on the call last week, leadership has put forward proposed updates for recommendation #4 in the google doc to reflect the input that was received during the call. Best regards, Caitlin, Berry and Marika EPDP Phase 2A - Meeting #38 Proposed Agenda Tuesday 24 August 2021 at 14.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (Chair) (5 minutes) 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: timeline to get to Final 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. * Update on status of recommendation #3 · Small team status update · Confirm next steps * Review of Recommendation #4 (second reading) · Consider input provided · EPDP Team discussion · Confirm next steps * Review of recommendation #5 (second reading) · Consider input provided · EPDP Team discussion · Confirm next steps * Review of recommendation #1 (third reading – if updated language is received) · Consider additional input provided · Consider leadership path forward · Confirm next steps * Review of recommendation #2 (third 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 #39 Thursday 26 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 | 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