<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"></head>
<body>
I agree with the concept described here, although I differ on some
specifics, and I thank Matt, Alan, Marc and Matthew for bringing it to
the table.<br><br>
1. The email address issue was omitted<br><br>
2. The Web Form issue needs to be included, along with the rationale for
why it is needed (lack of endorsing anonymized or similar addresses in
the public RDDS).<br><br>
3. There is a conflict in the message between "(i.e., no changes to
the status quo from Phase I)" and the Rec 1 bullet saying no changes
to the optional differentiation. The standardized flag is a
change/addition to Phase 1 Recs.<br><br>
4. The dialog on Rec 3 asks whether there should be guidance. Guidance is
already in Rec 4. I thought the main point of disagreement is whether the
new flag must be used by those Rrs who do choose to
differentiate.<br><br>
Given that the focus is asking for input on the various issues that do
not have consensus, each issue must be presented with the pro and con
positions held by the various EPDP participants.<br><br>
Alan<br><br>
At 2021-05-28 04:42 PM, Crossman, Matthew via Gnso-epdp-team
wrote:<br><br>
<br>
<blockquote type="cite" class="cite" cite="">All,<br>
<br>
The RySG appreciates the Chair’s clarification that the Initial Report
is intended to share progress and solicit input, and is not a
representation of consensus on the proposed outputs. We also recognize
the importance of timely completion of this initial stage of our work.
With that in mind, if the team can agree on the following constructive
suggestions to ensure that the report appropriately describes the state
of the issues and facilitates community input on areas where there
remains significant divergence, the RySG is willing to withdraw our
“cannot live with†items as blockers for publication of the Initial
Report.<br>
<ul>
<li>In general, the report should be restructured with the aim of
soliciting community input rather than reporting specific outcomes. For
example, each section should describe the issue/question presented,
provide a description of the team’s views and areas of disagreement,
and then clearly present questions to the community where we require
additional input.
<li>Where the Initial Report includes specific recommendations, the text
should clearly note that there is significant disagreement on each
recommendation and that the team is soliciting community input to assist
in resolving those disagreements. For clarity in obtaining feedback, we
also suggest that the response to the charter questions from the GNSO
(i.e., no changes to the status quo from Phase I) should become a
standalone Recommendation #1.
<li>We propose the following questions for each of the recommendations
(existing questions in the Initial Report can be incorporated into this
list):
<ul>
<li><b>New Rec 1 (answer to charter question)</b>:
<ol>
<li>Is there new information or inputs that the Phase 2A team has not
considered in assessing whether to make changes to the recommendation
that Registrars and Registry Operators may, but are not obligated to,
differentiate between legal and natural persons?
</ol>
<li><b>New Rec 2 (GNSO Council monitoring)</b>:
<ol>
<li>Is this recommendation necessary for the GNSO council in considering
future policy work in this area? If yes, in what ways does this
monitoring assist the Council?
</ol>
<li><b>New Rec 3 (Standardized flag)</b>:
<ol>
<li>Should the working group provide guidance to registries and
registrars who choose to differentiate between legal and natural person
registrations as to how they make that distinction in their systems?
<li>If yes, what field or fields should be used and what possible values
should be included in the guidance?
</ol>
<li><b>New Rec 4 (Differentiation guidance)</b>
<ol>
<li>Does the guidance as written provide sufficient information and
resources to Registrars and Registry Operators who wish to differentiate?
<li>Are there additional elements that should be included?
<li>How useful is the legal guidance (substance and format) in assisting
Registrars and Registry Operators in differentiating?
</ol>
</ol>
<li>As part of ensuring that we receive informed feedback from the
community, out of context excerpts from the legal memos must be removed
from the main body of the report. As we have noted, the legal memos are
cumulative and rely on significant assumptions and analysis to reach a
conclusion on risk. The full legal memos should be appended to the report
to give the reader the full scope of the legal advice on differentiation,
verification, mitigation, and the relevant risks.
</ol> <br>
To be clear, we continue to stand by the concerns and issues we have
flagged. If not appropriately resolved, these concerns may prevent us
from providing consensus support on the final recommendations. However,
we intend our suggestions above as a constructive proposal to ensure that
the Initial Report is published as a tool to assist in gathering
additional feedback that may aid in the resolution of existing areas of
divergence.<br>
<br>
Look forward to discussing further.<br>
<br>
Thanks,<br>
Matt, Alan, Marc<br>
<br>
<b>From:</b> Gnso-epdp-team <gnso-epdp-team-bounces@icann.org>
<b>On Behalf Of </b>Caitlin Tubergen via Gnso-epdp-team<br>
<b>Sent:</b> Thursday, May 27, 2021 11:31 AM<br>
<b>To:</b> gnso-epdp-team@icann.org<br>
<b>Subject:</b> [EXTERNAL] [Gnso-epdp-team] Notes and action items - EPDP
Phase 2a Meeting #25 - 27 May 2021<br>
<br><br>
<b>CAUTION</b>: This email originated from outside of the organization.
Do not click links or open attachments unless you can confirm the sender
and know the content is safe.<br>
<br>
Dear EPDP Team,<br>
<br>
Please find below the notes and action items from today’s call.<br>
<br>
Best regards,<br>
<br>
Berry, Marika, and Caitlin<br>
<br>
<b><u>
<a href="https://docs.google.com/spreadsheets/d/17qLMYb3HC7qGYPQveXbUq5ZSzvedrQ3t8AdVdrRIdrw/edit#gid=0">
Action Items</a> <br>
<br>
</b> </u>
<ol>
<li>EPDP Team members are to
review<a href="https://mm.icann.org/pipermail/gnso-epdp-team/attachments/20210526/923483e1/InitialReportinputform-withproposedresolution-updated26May2021-0001.pdf">
the input form with the proposed resolution of cannot live with
items</a>, Keith’s email
(<a href="https://mm.icann.org/pipermail/gnso-epdp-team/2021-May/003937.html">
https://mm.icann.org/pipermail/gnso-epdp-team/2021-May/003937.html</a>)
the updated section 3 of the Initial Report
(<a href="https://drive.google.com/drive/u/0/folders/1TW3Z-s6DzS2QsV_VwJ6iUQTvKVIXQrmG">
https://drive.google.com/drive/u/0/folders/1TW3Z-s6DzS2QsV_VwJ6iUQTvKVIXQrmG</a>
) and indicate what changes/updates are essential FOR THE PURPOSE OF THE
PUBLICATION OF THE INITIAL REPORT in this
<a href="https://docs.google.com/document/d/1aaDULVrGIkWXEGfoal8RqkC_baNjmVvujgk1HIyoSbI/edit">
table</a> BY CLOSE OF BUSINESS, FRIDAY 28 MAY. As such, you are
encouraged to focus your input on any clarifying edits and/or questions
that should be added to encourage community input. Input table:
<a href="https://docs.google.com/document/d/1aaDULVrGIkWXEGfoal8RqkC_baNjmVvujgk1HIyoSbI/edit">
https://docs.google.com/document/d/1aaDULVrGIkWXEGfoal8RqkC_baNjmVvujgk1HIyoSbI/edit</a>
.
<li>Deadline for flagging any minor edits / corrections by 16:00 UTC on
Friday, 28 May.
(<a href="https://docs.google.com/document/d/1aaDULVrGIkWXEGfoal8RqkC_baNjmVvujgk1HIyoSbI/edit">
https://docs.google.com/document/d/1aaDULVrGIkWXEGfoal8RqkC_baNjmVvujgk1HIyoSbI/edit</a>
)
<li>RrSG and GAC to come forward with proposal for updated Guidance D to
factor in concerns addressed (References to “controller†are not
helpful as ICANN has recently avoided ‘admitting’ its controllership.
Each CP must determine for itself if/how data protection law might impact
its processing. This appears to be quasi-legal advice, which should be
avoided. We should also avoid paraphrasing the GDPR) by Friday, 28 May.
<li>IPC and GAC reps to come forward with a proposal for footnote 8, “8
The personal/non-personal distinction only applies/is relevant for
registrants who have self-identified as legal persons†by Friday, 28
May.
<li>RySG to come forward with a proposed question to put forward to the
community in relation to the standardized data element to obtain further
input on whether changes should be considered to the terminology used or
the type of data element proposed by Friday, 28 May. 27.
<li>GAC to liaise with RySG to address the concerns of the RySG regarding
the GAC-proposed feasibility recommendation. (Note: GAC has suggested the
RrSG proposed suggestion could be a viable alternative.)
<li>Groups who support including a recommendation on webforms to
formulate specific questions for community input factoring in the
concerns of other groups that have been expressed on the mailing list.
</ol><b> <br>
EPDP Phase 2A - Meeting #25<br>
Proposed Agenda<br>
</b>Thursday 27 May 2021 at 14.00 UTC<br>
<br><br>
1.
Roll Call & SOI Updates (5 minutes)<br><br>
<br><br>
2.
Welcome & Chair updates (Chair) (5 minutes)<br><br>
a. “Cannot live with†items take-aways<br>
- 77 items were
addressed as cannot live with, which is very concerning<br>
- Each group will
be asked to speak for 1-2 minutes about a proposed path forward for the
group. <br>
- Your group can
discuss a path forward in a general sense or discuss specific items<br>
- Cannot live with
items are typically used to indicate fundamental disagreement for a Final
Report. This group is not there yet. We are developing proposed text and
questions to seek public comment on.<br>
- Struggling with
the number of cannot live with items at this stage of the
process<br><br>
b. Approach & expected next steps for Initial
Report publication<br>
<br><br>
3.
Consider any remaining “cannot live with†items identified by EPDP
Team members after review of Initial Report input form with proposed
solution and redline version of updated Initial Report<br><br>
a. Consider items submitted prior to the
meeting<br>
- RrSG: Members
have approached this group and work with unrealistic expectations
regarding changes that are beyond the scope of this group’s work and
are unhappy that they cannot achieve what they want. <br>
- ALAC: part of the
issue is timing. To some extent, maybe if we had more time to talk,
digest, and consider these documents, there would have been more time to
consult with our constituencies. Many concerns were resolved with the
staff issues, but the other issues need to be resolved one-by-one.<br>
- BC: This is not
just the timing issue. There is also a tone issue. This is about optional
guidance; it is not about imposing requirements. In the ICANN model, when
the status quo is favored, you have the option to be magnanimous when
opposing change. BC has been on both sides; however, BC has never
brutally disparaged other interests, but that is happening in this group.
<br>
- RrSG: Interesting
to hear ALAC and BC raise similar concerns as the RrSG. RrSG’s concerns
that have been repeatedly raised are hidden in footnotes. It’s
important to ensure arguments have equal time. <br>
- GAC: Believe the
group is closer than we think – confident that we can geet to “yesâ€
with everyone being equally unhappy. When GAC reviewed additions from the
RySG and saw what was a neutral but barebones description, GAC thought it
needed to include the same so that there is a balance. It is fair for
everyone to be mindful of wanting to achieve a balanced and objective
view in the report as to the state of play and clear indications of where
we disagree for the purpose of soliciting public comments. If some groups
put in text that tilt the scales, they should expect the other side to
respond. It’s fair to ask everyone to forbear but not reasonable to
expect groups to not put their perspective down. It may be helpful for
groups to mutually disarm. We may need another week to review the changes
that Staff has made. <br>
- Beyond a week
extension, we would need to go back to the Council for a project change
request. <br>
- NCSG: Think we
should modulate our expectations for this report. Even though we are
arguing about fine points. It is fair in an initial report – we worked on
this for [xx] months, there are still firmly-held positions. One side
says this, and the other side says this, so that it’s clear to the
reader what the two positions are. We should not pretend we have
consensus when we don’t. <br>
- ALAC: in taking a
look at the contentious parts of the report – the introduction is very
contentious. With respect to the actual substance and concrete
recommendations of the report, the group is closer to consensus. <br>
- IPC: More time
may be needed to digest the changes. It would be helpful to have the line
numbers updated for the new version. <br>
- ISPCP: Pleased to
review Keith’s email – did not put any can ™t live with items in this
table. There seems to have been a lot of time devoted to items that are
not in scope. What we may be seeing here is a process where items that
are out of scope are not included in this report and a process of
mourning. We need more time for reflection on the scope. Based on these
conversations, it seems that we may be closer than we thought. <br>
- SSAC: Concerned
with getting the group back on track and working toward consensus.<br>
- RySG: RySG has
made interventions re: scope. This group has a specific task to go by.
EPDP has become a work horse where groups continually bring things to the
table. There are a lot of eyes on the MSM; it’s important to follow the
process and stay in scope. If we do not agree with the guidance or agree
that it will be helpful to CPs, then it is not good guidance. It’s
important to point out in FN13 that three of the members of this team
believe that this should be mandatory. There has been a mixed message.
<br>
- Thank you to all
for the frank conversation. There is a general view that we are closer
than it appears. There is a recognition that we can do some work over the
next week and that we need to clearly resolve some of the cannot live
with designations. We need everyone to go back to the cannot live with
designations. These are significant and mean something when staff and
leadership does its analysis to try to resolve issues. The way forward:
all groups to review the responses to the cannot live with items, review
Keith’s email from yesterday, and the latest version of the Initial
Report with the redlines. What needs to be added in terms of questions to
ensure we get meaningful input in the public comment forum. <br><br>
b. Confirm next steps<br><br>
<br><br>
4.
Consider items flagged for further discussion and resolution (see list of
blue items):<br><br>
a. Should standardized data element
recommendation include reference to extensibility? Is this a necessary
missing element or can this also be considered after public comment?<br>
- This is a field
meant to talk about registrant type. There may be value in not unduly
restricting this field if we want to expand this field in the
future.<br>
- Registries do not
support this as a field in the public RDDS, but do support this being a
standardized data element for registrars who choose to differentiate.
Concerned with the fields we have standardized own – this seems to
contradict the Teamâ’s own advice that legal/natural distinction is not
dispositive for whether the registration contains personal data or not.
Concerned that legal/natural/unknown are not the right fields. For that
reason, wise of SSAC to suggest some flexibility here. <br>
- This is in the
RDDS period – a qquestion later on is if this should be public. The
Initial Report asks a question about whether this should be sent to the
SSAD. Thought “unknown†was changed to “unspecified†since
unknown is unclear as to who doesn’t know it. <br>
- Seems that RySG
is saying the data element should be extensible, could be for example,
legal but contains personal data. That statement does not contradict the
statement from SSAC. Agree that “unknown†is not as good as
“unspecifiedâ€. <br>
- RySG to include a
question for public comment re: this field. The question is around the
fields to be standardized, and we need to come to agreement on a question
to pose that can help inform the discussion on this. If the text
doesn’t have the right fields, we need input on how to get input on
what the right fields are. <br>
- ALAC is adamant
that the field should be added to RDDS, not necessarily the public RDDS.
If there are too many values, the field may not have as much utility.
<br>
- If there are not
the right fields, what could they be, what should they be?<br>
- This is a
question of sorting. This is an initial sorting of legal, natural, or
unspecified. The question of whether personal data is present, is a
separate analytical issue. This concern is already reflected in the
guidance. <br>
- The distinction
b/w legal and natural is not relevant for all data protection law. The
whole idea of managing personal information by asking about legal v.
natural misses the point. <br><br>
b. Footnote 5 – GAC to confirm whether this
footnote must remain as it is a cannot live with item for the IPC.
Footnote was originally added at the request of the GAC. <br><br>
c. LvN Background Information D. – GDPR
Principlles that may apply. RrSG Team has indicated that this is
important guidance to Registrars, others (IPC, GAC, ALAC, GAC) have
indicated concerns with this language. GAC & RrSG were assigned
action item to come up with a mutually acceptable approach.<br>
- GAC has no
opposition to referencing principles; however, uncomfortable with
paraphrasing the GDPR and picking certain principles over others. <br>
- Not in favor of
striking section D – it’s important to conveyy the GDPR principles.
This is a way to incorporate the guidance registrars have been trying to
provide all along. <br><br>
d. New recommendation (submitted after the
deadline) re. LvN Guidance<br>
- The guidance does
not include the key advice – if the legal registration does not include
personal information, it should be published. The “money issue†is
omitted – it’s only includeed in the scenarios, which is not guidance.
This issue has been raised all along – this is a real, true cannot live
with item. <br>
- Support previous
comment – we have guidannce, which is not mandatory, saying if you choose
to differentiate, this is how to do it, but we don’t have the result of
it. In other words, every registrar could differentiate, but there is
still nothing published. The registry comment is talking about publishing
the type, and this is not what the sentence is saying. This is about
publishing the actual data, not the flag. <br>
- This is something
that registrars can decide to do field by field. <br>
- Question is to
the registries – this feedback is based on a differennt topic than what
the text was. This appears to relate to the publication of the
legal/natural flag. <br>
- Can agree to a
should but not a must<br>
- Do not agree with
the two-levels of permissiveness – it’s already guidance – why does it
at also need to say should?<br><br>
e. New recommendation (submitted after the
deadline) re. web forms<br>
- The target of a
PDP should not be “we followed the rulesâ€; the target should be good
policy. If we are not going to recommend pseudonymized emails, there is
an impact of that decision, and that is why the web form recommendation
is suggested. <br><br>
f. New recommendation (submitted after the
deadline) re. feasibility<br>
- This is not a new
concept; this is the crux of these discussions so that it can be
identified for public comment. With the registrar’s suggested text,
hoping to get to “yesâ€. <br>
- Is this new
language being proposed as guidance?<br>
- Answer:
yes.<br><br>
g. Confirm next steps<br>
- Provide an
opportunity or a path for including the bracketed language unless there
is strong disagreement.<br>
- If there is
general agreement that this text can be included after additional
wordsmithing; however, if there is significant disagreement, may have to
set them aside. <br>
- Over the next
24-36 hours, please spend time on these outstanding items to get this
across the finish line. Plan to schedule meetings on Tuesday and Thursday
<br>
<br><br>
5.
Public Comment Forum <br><br>
a. EPDP Team to provide suggestions for how to
best solicit input from the community and avoid restatements of already
known positions and/or information.<br><br>
b. Confirm next steps<br>
<br><br>
6.
Homework assignments reminder <br><br>
<br>
· <u>By Friday 28 May at
16.00 UTC</u>, EPDP Team to review latest version of the Initial Report
and submit any minor edits / non-substantive comments. <br>
<br><br>
7. Wrap and confirm next EPDP Team meeting
(5 minutes):<br>
a. EPDP Team Meeting #26 Tuesday 1
June at 14.00 UTC (if necessary)<br>
b. Confirm action items<br>
c. Confirm questions for ICANN Org,
if any<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Gnso-epdp-team mailing list<br>
Gnso-epdp-team@icann.org<br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-epdp-team" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-epdp-team</a><br>
_______________________________________________<br>
By submitting your personal data, you consent to the processing of your
personal data for purposes of subscribing to this mailing list accordance
with the ICANN Privacy Policy
(<a href="https://www.icann.org/privacy/policy" eudora="autourl">
https://www.icann.org/privacy/policy</a>) and the website Terms of
Service
(<a href="https://www.icann.org/privacy/tos" eudora="autourl">
https://www.icann.org/privacy/tos</a>). You can visit the Mailman link
above to change your membership status or configuration, including
unsubscribing, setting digest-style delivery or disabling delivery
altogether (e.g., for a vacation), and so on.</blockquote></body>
</html>