Page History

Notes/ Action Items

 Action Items

1. Support Staff to create a clean "cannot live with" table and an updated redline Section 3 that incorporates (i) the non-substantive grammatical changes (which were highlighted in green) and (ii) the EPDP Team agreements from today's meeting. (complete)
2. Support Staff to propose compromise language based on the outstanding items from today's discussion. (complete)
3. EPDP Team to review the updated Section 3 document and populate any further "cannot live with" items based on the four highlighted questions (on p. 3, 7, and 9 of the redline Section 3 doc) into the new "cannot live with" table by 17:00 UTC on Monday, 30 August.

EPDP Phase 2A - Meeting #39

Proposed Agenda

Thursday 26 August 2021 at 14.00 UTC

1. Roll Call & SOI Updates (5 minutes)
2. Welcome & Chair updates (Chair) (5 minutes)
3. Consider and resolve “cannot live with” items for section 3 of Final Report - Responses to Council Questions & Recommendations (75 minutes) – see

https://docs.google.com/document/d/1knSKHXt0njWqXMmpiDKA76amycenNBUl/edit

As a reminder: timeline to get to Final Report

26 August – consider “cannot live with” items identified & 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.

2 September – submission of Final Report to GNSO Council

10 September – final deadline for minority statements (any minority statements submitted after 30 August will be added to the Final Report, with the updated version to be submitted to the Council in time for the September meeting document deadline)

1. Review “cannot live with” items identified
   • Goal is to publish the integrated draft Final Report, following agreed upon next steps, including statement on consensus
   • 31 August – address remaining issues
   • May need to pencil in 2 September as a tentative meeting to resolve final issues, if any
   • Support Staff grouped the items that were flagged to better organize today’s discussion.
   • The first issue is the proposal to the GNSO Council – there are two specific proposals here. The first is to delete reference to implementation plans. Also, some noted that language in second part should be more specific.
   • Ultimately, it is still the Council’s decision when it would take on more scoping work.
   • Question for the Team to consider: would any of these changes being proposed result in “cannot live with” items for other groups?
   • The default should be does everyone agree not the other way around. Future changes should be defaulted to everyone cannot live with unless they say that they can.
   • Some note the reference to 9.4.4 in this recommendation should be deleted, as this is already referenced later in the report.
   • Question to the group – would the cannot live with item be resolved by deleting “which indicates that a Contracted Party needs to have a mechanism to identify that a registration record does not contain any personal data.”
   • Groups can live with the proposed compromise here
   • The question to the group is – is the new version preferred over the previous version?
   • There is a difference in the Phase 1 rec. between 17.1 and 17.3 – the important point to make is to resolve the legal v. natural issue, but not all are convinced that the legal v. natural issue was resolved.
   • Would the group be OK with removing lines 87-91 and move these opinions to the minority statements, or if not, group should consider the proposed edits.
   • Not everyone will read the minority statements, so this text should be included in the text of the report.
   • Do not agree to remove this text, this constitutes whitewashing the report, as most readers will not read the minority statements
   • The report should accurately reflect the context in which the recommendation is given – that is why this preamble is important. Agree to be concise, but should not be whitewashed.
   • This does seem to be a significant change to be making at this stage.
   • This text detracts from the report and do not agree that this is whitewashing. If the Team lands on retaining this section, it needs to be clear that the paragraph does not belong in the previous section to GNSO Council.
   • If these are kept, they should be moved to footnotes so as to be clear that these are not part of the recommendation or policy. Whether or not someone reads the minority reports should not be this team’s concern – what matters most is how the recommendations are implemented, and the text needs to be clear for that reason.
   • The next edits apply to recommendation #1 and the footnote added.
   • It is important to maintain the option to create this field within their own platform – not just RDDS or SSAD.
   • Not concerned with what CPs are doing individually – the change from a must to a may is changing the entire concept of what was being discussed. The purpose is that when the fields are created is for all to use them.
   • It is coming back to haunt the Team that the Team is using different language to create these fields than we are using to create all other fields for Phase 1.
   • See value in having the field displayed somewhere, but do not think there is consensus on this.
   • Most important that the field is created.
   • The proposed changes from Staff Support reflect what the group agreed to.
   • Believe the group agreed to creation of an optional field that is similar to other RDDS fields – perhaps a footnote that makes this crystal clear is necessary. If we are talking about something that is just part of the registrar system, that is akin to a credit card field.
   • Suggest update to the specific contact provisions – the RDDS Spec of the CL&D policy
   • No members of the CPH team are supportive of using the field in RDDS at all
   • In the small team, there was agreement that there should be no prohibition in using this field in RDDS, but do see value in a standardized system, in particular for use and integration with SSAD
   • The terminology of RDDS was included originally so that there was a clear trigger for ICANN org to initiate the process outside of ICANN in the standards bodies in developing the RDAP extension – this field must be created. The language regarding RDAP and RDDS is now causing challenges – perhaps we could change this to a field must be created and include a footnote to enable or initiate this process to create a new extension.
   • Can the group not have a must and have a few mays in the same sentence – a field MUST be created and then tie to this language: The EPDP expects that the technical community, for example the Registration Data 119 Access Protocol (RDAP) Working Group, will develop any necessary standards associated with such fields. Having one long sentence is a bit confusing.
   • Fundamentally, the group has agreement that the new field must be created and must be used by those who differentiate. The specificity is the problem. RDDS may be one option for the use of such a field, but there may be other uses as well. Please provide suggested text either during the call today or shortly thereafter to move this forward.
   • Suggest that breaking the paragraph apart could help so that there is clear delineation between the must and the mays. Impression about the may be used in RDDS and the connection to the footnote – in RDAP, if there is no value in that field, it never gets transferred. Impression about the may – is that if a registrar chose to display this field, if they chose to publish it, it would mimic the Phase 1 recommendation the additional data element – for example, if .medical TLD requires additional registration requirements and they wanted it to be published, it would fall in as an additional data element that CPs could choose to publish as part of minimum public data set, but it would fall in with CL&D – in that it would be published at the bottom.
   • The original proposed language from the small team – field must be created that may be used by the contracted parties – that was the first draft and what was originally discussed. That was later amended to created or extended in RDAP. Finally, that was changed to “created for the RDDS” – these successive edits change the meaning. CPs agreed to a standard data element and agreed that it could be used in RDDS.
   • Action: Staff and Leadership team will come forward with proposed text for the group to consider.
   • Regarding ALAC’s comment about default values, registries did not have adequate time to discuss if this a cannot live with value. However, not clear why not having default values is a cannot live with item.
   • In terms of default value, the possible values are legal, natural, unspecified (which means registrant said will not say), or the question has never been asked. The default value should be no data has been provided.
   • Defining a field with four distinct values and would like clarity on what would be the default.
   • If advising a registrar would advise to ignore what a registrant says if not sure about geographic whereabouts – it is entirely possible for the field to be blank, vacant, or deleted.
   • May want to ignore the value, but do not agree that therefore you must not record the value. The default value is that you don’t anything and don’t know. How that translates into subsequent action is a separate matter.
   • The first value is the most innocuous and should be the default – looking for clarity for the implementation team.
   • RySG comment to change SHOULD to MAY – disagree with this change as it undermines the effort of many members
   • Could “are encouraged to” be in replace of should?
   • This guidance may be applicable in all jurisdictions and all cases – therefore this suggestion is not applicable in all cases. This is not an attempt to water down the language – just heard some pushback around the word should.
   • The point is you should follow the guidance – one of the reasons some would like the guidance is it helps to establish a normative direction. Could live with are encouraged to.
   • “Such flagging would facilitate” – RySG recommend changing would to could, as this is speculative.
   • No objections, so change applied.
   • Staff to update Section 3 in a redlined format and flag outstanding items from Support Staff’s side re: Rec. 1 and use it for further exercise of cannot live with.
   • Question from Staff – what does “within ICANN” mean in the context in the Code of Conduct? Noting that a code of conduct was not part of phase 1 or 2.
   • RrSG note that point ii under Rec. 5 is confusing – is this a cannot live with?
   • Is the yellow-highlighted change from strongly encourage to suggest considered a minor change to the Team?
   • What is the preferred way for the EPDP team to provide feedback?
   • Support Staff to create a clean table for the team to provide further input. Support Staff will also produce an updated redline so that everyone can see the what the changes will look like.
2. Agree on next steps

4. Wrap and confirm next EPDP Team meeting (5 minutes):

    a. EPDP Team Meeting #40 Tuesday 31 August at 14.00 UTC

    b. Confirm action items

    c. Confirm questions for ICANN Org, if any