Page History
...
Info |
---|
PROPOSED AGENDA
3. Continue review and updates to section 3 of Final Report - Responses to Council Questions & Recommendations (75 minutes) – seehttps://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.
b. Review of recommendation #5
c. Review of recommendation #1 (second reading)
d. Review of recommendation #2 (second reading)
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 c. Confirm questions for ICANN Org, if any
BACKGROUND DOCUMENTS See email invite with zoom webinar room URL for attendees (observers) |
Info | ||
---|---|---|
| ||
GNSO transcripts are located on the GNSO Calendar |
Tip | ||
---|---|---|
| ||
Apologies: Melina Stroungi (GAC), James Bladel (RrSG), Alan Woods (RySG), Brian Beckham (Co Chair), Sarah Wyld (RrSG), Chris Lewis-Evans (GAC) Alternates: Owen Smigelski (RrSG), Amr Elsadr (RySG), Ryan Caroll Carroll (GAC) |
Note |
---|
Notes/ Action Items Action Items
EPDP Phase 2A - Meeting #37 Proposed Agenda Thursday 19 August 2021 at 14.00 UTC
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# 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
b. Review of recommendation #5
c. Review of recommendation #1 (second reading)
d. Review of recommendation #2 (second reading)
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 |