<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Jeff -- thanks for encapsulating a bit of the problem and
concern. We're (non-contracted parties and GAC) are not returning
to our "ICANN day jobs," but to our real day jobs. It's the
Contracted Parties who have "ICANN day jobs," who are paid to
spend hours a day with ICANN,and hence who will be sitting on the
long-standing IRT. It's an interesting addition of a word -- and
underlies my concern. <br>
</p>
<p>Also, past is prologue. Or (to reference a recent holiday): why
is this IRT different from all other IRTs :-).</p>
<p>Best regards, Kathy<br>
</p>
<div class="moz-cite-prefix">On 5/13/2019 2:41 PM, Jeff Neuman
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CWXP265MB099978304A2E5AC450E57C9D900F0@CWXP265MB0999.GBRP265.PROD.OUTLOOK.COM">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"Times New Roman \,serif";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle27
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle28
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle29
{mso-style-type:personal;
color:#1F497D;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle33
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span style="color:windowtext">Thanks
Kathy. This too will be moved over for now to the smaller
list (when I get it confirmed that it has been set up). In
talking with a number of people, the creation of two groups
seems excessive and too much bureaucracy. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">If a
Post-launch IRT is set up, we will have to have some level
of trust that they will do the job put before them and only
the job put before them. We should not set up a second
group because we anticipate that the original group will
naturally act beyond its mandate. If we employed that
logic, then wouldn’t we need a third group to keep a watch
of the second group and so on.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">With respect
to everyone else “returning to their ICANN day jobs”, that
too should not be a problem that we would need to address.
One of the biggest failures of our current system is that we
as a community do not have trust in anyone else or any other
group to do the right thing. This leads unfortunately to a
situation where everyone believes that they need to be
involved in every issue and every group. But the reality is
that there are groups that are functioning well without
everyone being involved in everything. The Customer
Standing Committee is one example. Their job is to monitor
the performance of the IANA naming function and if
performance issues are not remedied, they may escalate
issues to the GNSO (and ccNSO). <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">If we set up
the group right, and we appoint responsible members to this
post launch IRT, then we should trust them to do the job
they are tasked with. We also should not be making
assumptions that this new post-launch IRT will be dominated
by contracted parties and applicants. We have the
opportunity to establish the rules of this new group so that
no one individual or group can control.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext">Best
regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><b><span
style="font-size:9.0pt;font-family:"Arial",sans-serif"
lang="EN-GB">Jeffrey J. Neuman</span></b><span
style="font-size:9.0pt;font-family:"Arial",sans-serif"
lang="EN-GB"><br>
Senior Vice President<o:p></o:p></span></p>
<p class="MsoNormal"><b><span
style="font-size:9.0pt;font-family:"Arial",sans-serif"
lang="EN-GB">Com Laude | Valideus<br>
</span></b><span
style="font-size:9.0pt;font-family:"Arial",sans-serif"
lang="EN-GB">1751 Pinnacle Drive , Suite 600<br>
Mclean , VA 22102<br>
UNITED STATES<br>
<br>
T: +1.703.635.7514<br>
M: +1.202.549.5079<br>
<br>
<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif"
lang="EN-GB"> <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Arial",sans-serif;color:windowtext"
lang="EN-GB"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Arial",sans-serif;color:windowtext"
lang="EN-GB">CONFIRMATION OF ORDERS: Please note that we
always confirm receipt of orders. To assist us in
identifying orders, please use the word ORDER in the
subject line of your email. If you have sent us an order
and have not received confirmation on the same working day
(PST) it is possible that your order has not been received
or has been trapped by our spam filter. In this case,
please contact your client manager or <a class="moz-txt-link-abbreviated" href="mailto:admin@comlaude.com">admin@comlaude.com</a>
for confirmation that the order has been received and is
being processed. Thank you.
<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="color:windowtext"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="color:windowtext">From:</span></b><span
style="color:windowtext"> Gnso-newgtld-wg
<a class="moz-txt-link-rfc2396E" href="mailto:gnso-newgtld-wg-bounces@icann.org"><gnso-newgtld-wg-bounces@icann.org></a>
<b>On Behalf Of </b>Kathy Kleiman<br>
<b>Sent:</b> Sunday, May 12, 2019 10:54 PM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:gnso-newgtld-wg@icann.org">gnso-newgtld-wg@icann.org</a><br>
<b>Subject:</b> Re: [Gnso-newgtld-wg] FW: Follow up from
May 6th and CALL FOR SMALL GROUP<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>Hi All,<o:p></o:p></p>
<p class="MsoNormal">I have read the discussion taking place and
I still don't think the key issues or concerns have been
addressed. I'm glad that the Board, the Community, GNSO
Council members, Staff and Post-Launch Standing IRT members
<b><i>can raise Policy issues, Implementation issues and
Policy/Implementation borderline issues. But my question
is who decides what category these questions (from all
these Sources) fall into?
</i></b>Someone has to look at a question and decide whether
is it policy, implementation or borderline (implementation,
with substantial policy implications).
<o:p></o:p></p>
<p>To a long-standing Post-Launch Standing IRT, at work for
several years, most questions will appear to be
implementation. Why? Because to a hammer, almost everything
is a nail. The Post-Launch Standing IRT will be geared up to
solve everything as efficiently as possible -- to make
everything as <i>"predictable for applicants" </i>as
possible.
<b><i>Good, but what about the GAC, Non-Contracted Parties and
the Community? </i>
</b>We (this latter group) will have returned to our other
Multistakeholder Policy duties, to our other ICANN deadlines
and priorities, and frankly, to our day jobs. We won't be
watching when Staff flags a question to the long-standing
Post-Launch Standing IRT and they flag it as "implementation"
due to their focus on application processing (when it is
actually policy or implementation with a heavy policy impact,
e.g., systems involving the processing of public comments or
Objections). I'm not saying the lack of understanding of
policy implications of an issue will be intentional -- it is
likely inadvertent when seen through the prism of incumbents
and applicants.<o:p></o:p></p>
<p>How do I know this -- because virtually numerous IRTs in the
last decade have -- or been strongly urged -- to rewrite
policies (to rewrite consensus policies, agreed and accepted
by the Multistakeholder Community & Board).
<o:p></o:p></p>
<p>A Gateway Group will review all new questions coming through
-- hopefully in conjunction with a standing group of the GNSO
Council, the Community and Non-Contracted Parties, the GAC and
likely, a few members of the Post-Launch Standing IRT.
Especially as Staff arives with questions arising from the
application & comment process (policy/implementation
questions), this Gateway Group can quickly sort these
questions -- pointing them in the right direction: Council or
IRT. The Gateway Group should be diverse, fast and light
weight. The heavier implementation work, technical detail,
etc, belongs to the IRT.
<o:p></o:p></p>
<p>Overall, IRTs are IRTs. They will be tempted (and urged) to
rewrite policy; they will want to control as much as possible;
for these applications, they will be dominated by contracted
parties and applicants. That's the nature of the system;
that's the way virtually all recent IRTs have worked; and
their structure will incentivized to treat as much as
"implementation" as possible. If we are going to have a
Post-Launch Standing IRT, then we need one more step.<o:p></o:p></p>
<p>Best, Kathy<o:p></o:p></p>
<div>
<p class="MsoNormal">On 5/7/2019 4:05 PM, Aikman-Scalese, Anne
wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="color:#1F497D">Dear WG
members:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Regarding the
smaller group assembled to work on how staff and the
proposed “post-launch Standing IRT” might determine
whether an issue is policy or implementation, I would like
to clarify again the history that led to the existing GNSO
processes designed to address these issues whenever they
arise –either Pre- or –Post launch:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">The Policy
& Implementation Working Group grappled with this
question of policy versus implementation for many months
and concluded it was impossible to make determinations
about that in advance because “one person’s policy is
another person’s implementation”. That is exactly why we
have the result we have in the form of GNSO Input (which
is essentially for implementation issues), GNSO Guidance,
and GNSO EPDP. In fact, it was Marika Koenigs who first
suggested to the Policy & Implementation WG that,
based on our case studies of issues that arose in the 2012
round, it was impossible to “predict” issues that might
arise and label them as clearly policy or clearly
implementation. Jeff has pointed out that applicants want
more “predictability” in the process so that time delays
do not result. Thus, the proposed “Predictability
Framework” anticipates that ICANN staff and/or or some
newly created body will be able to decide issues that
arise post-launch. The “problem” Jeff is trying to
resolve as Co-Chair is that if an issue reaches the GNSO,
it may take too long to resolve and thus is not practical
for registry applicants. However, as far as I know, we
have not yet tried out these new processes (except for the
EPDP on the Temp Spec) so it seems to me a bit premature
to be inventing new processes and acronyms on top of the
ones that have not yet been tried.
<b>It strikes me that for various Implementation issues
that actually rise to the level of an issue post-launch,
the existing GNSO Input process (which has not yet been
used) is adequate and is in fact designed to operate in
that fashion since GNSO can raise such a concern “at any
time it deems appropriate”.</b></span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><u><span style="color:#1F497D">Under
existing GNSO processes established as a result of the
work of the Policy & Implementation Working Group</span></u><span
style="color:#1F497D">, the “gateway” is in fact a
question of the interaction between and among Staff, an
IRT (or Post-launch Standing IRT), and the GNSO Council.
Staff can raise an issue, IRT can raise an issue, and ANY
GNSO Council member can raise an issue and so these are
the “gates”. (In other words, there are multiple gates
and they all ultimately lead to oversight by GNSO
Council.) My own view (having worked actively in the
Policy & Implementation Working Group on several case
studies of issues that arose Post-Launch in the 2012
round) is that if an issue is truly implementation, no one
is going to raise the issue to the level of GNSO. Issues
will only rise to that level if a stakeholder believes
that GNSO Council should address it and that applies
whether it’s merely implementation (“GNSO Input” Annex)
or involves policy (“GNSO Guidance” Annex or “GNSO EPDP”
Annex). </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Before the
Sub Pro Initial Report issued, the Co-Chairs and staff
ultimately agreed to make reference to the GNSO Input,
Guidance, and EPDP processes but those processes were only
referenced and footnoted, not actually explained to the
ICANN community or the public. Importantly, the draft
Initial Report language was clarified to delete the
reference to the Standing IRT “deciding” an issue based on
the Predictability Framework. Instead, in the Initial
Report, there is a reference to the Standing IRT being
able to “recommend” a resolution of the issue. In terms
of ICANN governance and the ByLaws as modified after the
Policy & Implementation WG finished its work, that is
the correct stance. Establishing some other “gate” or
some method for determining in advance what is policy and
what is implementation when the existing processes adopted
after a full WG process have not been tried does not make
sense to me.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">By way of
additional background, the whole Policy &
Implementation Working Group evolved from the fact that
then-CEO Fadi Chehade decided that the “Strawman Solution”
in relation to trademarks was implementation, not policy.
Fadi issued a public statement to this effect. GNSO
Council members were upset about this and our Co-Chair
Jeff Neuman wrote the letter to the ICANN Board stating
that if the Board took action (such as the Strawman
Solution) that amounted to a change in policy, they had to
come back to GNSO for its views on the topic and more
specifically, to make a determination as to whether the
topic required more policy work or merely some GNSO
input.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Clearly the
timing as to when an issue arises (either pre- or post-
launch) is NOT a determiner of whether it is Policy or
Implementation. So Chuck Gomes led the P & I WG as a
result of the GNSO Council’s dissatisfaction with the
handling of that issue (and others) that arose Post-Launch
and we spent more than year (probably about 2 years)
reviewing numerous issues that arose after applications
were filed in the 2012 round. That is why the GNSO
processes called Input, Guidance and EPDP were adopted by
the GNSO Council and that is why the ICANN ByLaws were
amended.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Hopefully the
above history helps to clarify why I was quoting existing
GNSO Operating Procedures and Annexes. Again, I don’t
think the public understood these processes when the
Initial Report issued. The current Consensus Policy
Implementation Framework (“CPIF”) of the GNSO makes
specific reference to these processes and requires that
IRT members be briefed on them.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Anne</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Gnso-newgtld-wg [<a
href="mailto:gnso-newgtld-wg-bounces@icann.org"
moz-do-not-send="true">mailto:gnso-newgtld-wg-bounces@icann.org</a>]
<b>On Behalf Of </b>Jeff Neuman<br>
<b>Sent:</b> Tuesday, May 7, 2019 1:57 AM<br>
<b>To:</b> <a href="mailto:gnso-newgtld-wg@icann.org"
moz-do-not-send="true">gnso-newgtld-wg@icann.org</a><br>
<b>Subject:</b> [Gnso-newgtld-wg] FW: Follow up from May
6th and CALL FOR SMALL GROUP<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal"><strong><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif">[EXTERNAL]</span></strong><o:p></o:p></p>
<div class="MsoNormal" style="text-align:center"
align="center"><span
style="font-size:12.0pt;font-family:"Times New
Roman ,serif",serif">
<hr width="100%" size="1" align="center">
</span></div>
</div>
<p class="MsoNormal">All,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Following up on the call yesterday, we
have revised the document on the Proposed New Predictability
Model. You can find it here:
<a
href="https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGrBh4/edit?usp=sharing"
moz-do-not-send="true">
https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGrBh4/edit?usp=sharing</a>.
The comments made during the call should be incorporated
either as revised language itself, or as “comments” for
draft language to be created.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">As we discussed, we would like to have a
smaller group dedicated to working through the issues that
remain on this topic so that a more comprehensive proposal
can be presented to the full working group at a later date
on the Predictability Framework. The group is open to any
current Working Group members. However, if you join the
small group, you are expected to put in some time to try and
resolve whatever issues remain. The small group MAY have a
call or two, but the hope is that all of the work can be
done in e-mail and through the documents itself. We will
create a mailing list to work on these issues. This is NOT
a formal group.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">So far, I think we captured the following
people to be on this group (from the call last night):<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Jeff Neuman<o:p></o:p></p>
<p class="MsoNormal">Cheryl-Langdon Orr<o:p></o:p></p>
<p class="MsoNormal">Kathy Kleiman<o:p></o:p></p>
<p class="MsoNormal">Christopher Wilkinson<o:p></o:p></p>
<p class="MsoNormal">Kristina Rosette<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">There may have been others that already
volunteered, but may not have captured, so please indicate
your interest to us if you want to be a part of the smaller
team.
<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">We will not be doing formal consensus
calls as part of this smaller group, but rather just making
the proposal better and filling in the holes to present to
the full working group.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Please let me know if you have any
questions. <o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<p class="MsoNormal"><b><span
style="font-size:9.0pt;font-family:"Arial",sans-serif"
lang="EN-GB">Jeffrey J. Neuman</span></b><span
style="font-size:9.0pt;font-family:"Arial",sans-serif"
lang="EN-GB"><br>
Senior Vice President</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span
style="font-size:9.0pt;font-family:"Arial",sans-serif"
lang="EN-GB">Com Laude | Valideus<br>
</span></b><span
style="font-size:9.0pt;font-family:"Arial",sans-serif"
lang="EN-GB">1751 Pinnacle Drive , Suite 600<br>
Mclean , VA 22102<br>
UNITED STATES <br>
T: +1.703.635.7514<br>
M: +1.202.549.5079</span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif"
lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Arial",sans-serif"
lang="EN-GB"> </span><o:p></o:p></p>
<p class="MsoNormal"><span
style="font-size:8.0pt;font-family:"Arial",sans-serif"
lang="EN-GB">CONFIRMATION OF ORDERS: Please note that we
always confirm receipt of orders. To assist us in
identifying orders, please use the word ORDER in the
subject line of your email. If you have sent us an order
and have not received confirmation on the same working
day (PST) it is possible that your order has not been
received or has been trapped by our spam filter. In
this case, please contact your client manager or
<a href="mailto:admin@comlaude.com"
moz-do-not-send="true">admin@comlaude.com</a> for
confirmation that the order has been received and is
being processed. Thank you.
</span><o:p></o:p></p>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Gnso-newgtld-wg <<a
href="mailto:gnso-newgtld-wg-bounces@icann.org"
moz-do-not-send="true">gnso-newgtld-wg-bounces@icann.org</a>>
<b>On Behalf Of </b>Julie Hedlund<br>
<b>Sent:</b> Monday, May 6, 2019 11:40 PM<br>
<b>To:</b> <a href="mailto:gnso-newgtld-wg@icann.org"
moz-do-not-send="true">gnso-newgtld-wg@icann.org</a><br>
<b>Subject:</b> [Gnso-newgtld-wg] Notes and Action Items
- New gTLD Subsequent Procedures PDP WG - 06 May 2019<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoPlainText">Dear Working Group members,<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Please see below the notes from the
meeting today, 06 May 2019. These high-level notes are
designed to help WG members navigate through the content of
the call and are not a substitute for the recording,
transcript, or the chat, which will be posted at: <a
href="https://community.icann.org/display/NGSPP/2019-05-06+New+gTLD+Subsequent+Procedures+PDP"
moz-do-not-send="true">
https://community.icann.org/display/NGSPP/2019-05-06+New+gTLD+Subsequent+Procedures+PDP</a>.
<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Please also see the referenced
documents at: <a
href="https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-w/edit?usp=sharing"
title="https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-w/edit?usp=sharing"
moz-do-not-send="true">https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-w/edit?usp=sharing</a>.<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Kind regards,<o:p></o:p></p>
<p class="MsoPlainText">Julie<o:p></o:p></p>
<p class="MsoPlainText">Julie Hedlund, Policy Director<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText"><b>Notes and Action Items:</b><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><b>Action Items:</b><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">ACTION ITEM 1: Staff to incorporate edits
as discussed into the 2.2.2 Predictability document.<o:p></o:p></p>
<p class="MsoNormal">ACTION ITEM 2: Gather a small group to
further develop the 2.2.2 Predictability document at:
<a
href="https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGrBh4/edit#heading=h.8vi2q2obcb8w"
moz-do-not-send="true">
https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGrBh4/edit#heading=h.8vi2q2obcb8w</a>.
Jeff will send out a call for volunteers to the list.
Volunteers thus far: Kristina Rosette, Kathy Kleiman and
Christopher Wilkinson.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><b>Notes:</b><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">1. Updates to Statements of Interest
(SOIs): No updates provided.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">2. Review of Summary Documents – (see: <a
href="https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-w/edit?usp=sharing"
moz-do-not-send="true">
https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-w/edit?usp=sharing</a>)<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">a. Continued: 2.2.2 Predictability /
2.2.2.2 Clarity of Application Process: See:
<a
href="https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGrBh4/edit#heading=h.8vi2q2obcb8w"
moz-do-not-send="true">
https://docs.google.com/document/d/12_x8zYR9r6zXqfA7dmoosSPH12NmcyJ-2FEjecGrBh4/edit#heading=h.8vi2q2obcb8w</a><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">-- Note: If we don’t come to consensus on
a topic then the status quo will be as it was implemented in
2012. On the record that some do not support that approach.<o:p></o:p></p>
<p class="MsoNormal">-- There are some different things
relating to IRTs that could be new.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">2.2.2 Predictability:<o:p></o:p></p>
<p class="MsoNormal">-- Added bullet: <i>The Predictability
Model <u>complements</u> the existing GNSO processes and
procedures and shall not in any way operate to be a
substitute or replacement for those. In fact, they are
incorporated into the Predictability Framework explicitly.</i><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><u>Discussion</u>:<o:p></o:p></p>
<p class="MsoNormal">-- “they” references existing processes
and procedures.<o:p></o:p></p>
<p class="MsoNormal">-- To avoid any doubt in future we might
want to add, “In the event of a conflict, existing GNSO
processes and procedures take precedent.”<o:p></o:p></p>
<p class="MsoNormal">-- Change from “shall not in any way
operate to be” to “is not intended to be”.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">What are we proposing:<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><u>B. Changes to ICANN Organization
Internal Processes</u><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><u>Discussion:</u><o:p></o:p></p>
<p class="MsoNormal">-- Comfortable that we have a distinction
for minor changes.<o:p></o:p></p>
<p class="MsoNormal">-- For the first bullet under (b) -- re:
“anything visible” -- what does that encompass? Add “change
the application or any of the other processes set forth in
the applicant guidebook”. Or “those parts of the
application that are scored”?<o:p></o:p></p>
<p class="MsoNormal">-- Third bullet -- New processes: Some
examples have direct relevance for the entire community.
Such as a new public comment platform.<o:p></o:p></p>
<p class="MsoNormal">-- Standing IRT decides what is
implementation or policy -- but some WG members disagree.<o:p></o:p></p>
<p class="MsoNormal">-- Change to “Material adverse impact”?<o:p></o:p></p>
<p class="MsoNormal">-- Second bullet -- “all non-minor
changes” -- in written policy? Answer: The output of this
whole thing will eventually be the AGB and if there are
changes to the AGB they would be written.<o:p></o:p></p>
<p class="MsoNormal">-- So not a reasonable response that a
process will just take longer -- just being a communication.
Seems like there should be more accountability. Add a
comment/note to see if that falls under a different
category.<o:p></o:p></p>
<p class="MsoNormal">-- Filter out those things that can be
dealt with in a practical matter.<o:p></o:p></p>
<p class="MsoNormal">-- Third bullet: Need a gateway process
before we get to these items. Wherever something affects
the underlying rules has huge implications.
<o:p></o:p></p>
<p class="MsoNormal">-- Might need to clarify: “New public
comment platform” means changes to the tools being used to
submit. The rules for commenting is the same, but the
platform is different.<o:p></o:p></p>
<p class="MsoNormal">-- Second bullet: Not meant to be a
change in the timing, but a change in a portal. <o:p></o:p></p>
<p class="MsoNormal">-- Add a line after bullet three, “These
proposed changes are intended to be only those that involve
mechanisms with no substantive impact.” Question: How is
that different from this text, “but rather a New ICANN
Organization Internal Process and it is likely to have a
materially [adverse] impact on applicants or community
members…” Seems similar in meaning.<o:p></o:p></p>
<p class="MsoNormal">-- An example of a change that wouldn’t
be substantive but could have a material adverse impact
would be requiring that Legal Rights Objections be filed
through a proprietary platform instead of email. Wouldn't
affect the substantive LRO (elements, standing, etc), but
there may be some potential objectors that, for one reason
or another, can't use that platform.<o:p></o:p></p>
<p class="MsoNormal">-- Are timelines on filing objections
seen as a different type of timeline as a third-party
timeline?<o:p></o:p></p>
<p class="MsoNormal">-- What might be a minor change for one
party could be a major change to others. Adverse outcomes
-- for whom? Should there be a policy gateway to determine?
We don’t have a framework that would be considered to be
predictable.<o:p></o:p></p>
<p class="MsoNormal">-- If there is a gateway then that could
delay any changes.<o:p></o:p></p>
<p class="MsoNormal">-- Overriding principle is
predictability. Trying to improve predictability from the
last round.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">C. <u>Fundamental Possible Policy Level
Changes</u><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><u>Discussion:</u><o:p></o:p></p>
<p class="MsoNormal">-- Some examples seem to be out of scope
for an IRT.<o:p></o:p></p>
<p class="MsoNormal">-- Deciding something that is policy: a
standing IRT can raise that issue and the GNSO Liaison can
take that back to the Council. Any Council member also can
raise something for consideration at the Council level.<o:p></o:p></p>
<p class="MsoNormal">-- So a standing IRT can raise something,
but only the Council can decide what is policy or
implementation, but it sounds like we are setting up a
separate gateway. The standing IRT cannot be the final
arbiter, and the Council also can raise it directly.<o:p></o:p></p>
<p class="MsoNormal">-- Add to the bullet point that the
standing IRT can make a recommendation to the GNSO Council
as to whether something is policy or implementation, but the
GNSO will make the final decision.<o:p></o:p></p>
<p class="MsoNormal">-- Ensure that this document is
cross-referenced to the current policies and processes for
IRTs.<o:p></o:p></p>
<p class="MsoNormal">-- What do we mean by “Staff will
collaborate with the community”? Answer: That is meant to
first go to the standing IRT, which makes a recommendation
for additional consideration, and then the GNSO decides how
to handle it -- GNSO Input Process, EPDP, etc.<o:p></o:p></p>
<p class="MsoNormal">-- Delete this text, “Staff will
collaborate with the community to consider the issue and
agree upon the mechanism by which the solution will be
developed. Options could include:” And emphasize the point
that this is meant to be a community+staff decision, not
just staff. Mark them as redlined and to be replaced. Come
back to this in another WG meeting.<o:p></o:p></p>
<p class="MsoNormal">-- Helpful to have a workflow diagram for
the Predictability Framework once concepts are agreed and
reconcile with existing ones from IRT Guidelines.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">D. <u>Fundamental Possible Policy Level
New Proposals</u> <o:p>
</o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><u>Discussion</u>:<o:p></o:p></p>
<p class="MsoNormal">-- Carry over changes from bullets under
C.<o:p></o:p></p>
<p class="MsoNormal">-- Reaching out to the community means
staff reaching out to the standing IRT. But don’t think the
standing IRT has the authority to decide if something is a
policy or implementation change. Could have a new group
that includes members of the IRT, and also Council members,
and then decide if it goes to the standing IRT.<o:p></o:p></p>
<p class="MsoNormal">-- Want to change what we call this
because of previous problems with IRTs. Want to get the
composition right so it is representative of the community.
Meant to ensure that it is a gateway.<o:p></o:p></p>
<p class="MsoNormal">-- A number of groups supported the
recommendations in the Initial Report but also some
dissenting views: ACTION: Form a smaller group to further
develop this document for the full WG. Volunteers thus far:
Kristina Rosette, Kathy Kleiman and Christopher Wilkinson.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<div class="MsoNormal" style="text-align:center"
align="center"><span
style="font-size:12.0pt;font-family:"Times New Roman
,serif",serif">
<hr width="100%" size="1" align="center">
</span></div>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New Roman
,serif",serif">The contents of this email and any
attachments are confidential to the intended recipient.
They may not be disclosed, used by or copied in any way by
anyone other than the intended recipient. If you have
received this message in error, please return it to the
sender (deleting the body of the email and attachments in
your reply) and immediately and permanently delete it.
Please note that the Com Laude Group does not accept any
responsibility for viruses and it is your responsibility
to scan or otherwise check this email and any attachments.
The Com Laude Group does not accept liability for
statements which are clearly the sender's own and not made
on behalf of the group or one of its member entities. The
Com Laude Group includes Nom-IQ Limited t/a Com Laude, a
company registered in England and Wales with company
number 5047655 and registered office at 28-30 Little
Russell Street, London, WC1A 2HN England; Valideus
Limited, a company registered in England and Wales with
company number 06181291 and registered office at 28-30
Little Russell Street, London, WC1A 2HN England; Demys
Limited, a company registered in Scotland with company
number SC197176, having its registered office at 33
Melville Street, Edinburgh, Lothian, EH3 7JF Scotland;
Consonum, Inc. dba Com Laude USA and Valideus USA,
headquartered at 1751 Pinnacle Drive, Suite 600, McLean,
VA 22102, USA; Com Laude (Japan) Corporation, a company
registered in Japan having its registered office at Suite
319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For
further information see
<a href="https://comlaude.com" target="_blank"
moz-do-not-send="true">www.comlaude.com</a> </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div class="MsoNormal" style="text-align:center"
align="center">
<hr width="100%" size="2" align="center">
</div>
<p class="MsoNormal"><span
style="font-size:7.5pt;font-family:"Arial",sans-serif;color:gray"><br>
This message and any attachments are intended only for the
use of the individual or entity to which they are
addressed. If the reader of this message or an attachment
is not the intended recipient or the employee or agent
responsible for delivering the message or attachment to
the intended recipient you are hereby notified that any
dissemination, distribution or copying of this message or
any attachment is strictly prohibited. If you have
received this communication in error, please notify us
immediately by replying to the sender. The information
transmitted in this message and any attachments may be
privileged, is intended only for the personal and
confidential use of the intended recipients, and is
covered by the Electronic Communications Privacy Act, 18
U.S.C. §2510-2521.
<br>
</span><br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Gnso-newgtld-wg mailing list<o:p></o:p></pre>
<pre><a href="mailto:Gnso-newgtld-wg@icann.org" moz-do-not-send="true">Gnso-newgtld-wg@icann.org</a><o:p></o:p></pre>
<pre><a href="https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg" moz-do-not-send="true">https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg</a><o:p></o:p></pre>
</blockquote>
</div>
<hr>
The contents of this email and any attachments are confidential to
the intended recipient. They may not be disclosed, used by or
copied in any way by anyone other than the intended recipient. If
you have received this message in error, please return it to the
sender (deleting the body of the email and attachments in your
reply) and immediately and permanently delete it. Please note that
the Com Laude Group does not accept any responsibility for viruses
and it is your responsibility to scan or otherwise check this
email and any attachments. The Com Laude Group does not accept
liability for statements which are clearly the sender's own and
not made on behalf of the group or one of its member entities. The
Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company
registered in England and Wales with company number 5047655 and
registered office at 28-30 Little Russell Street, London, WC1A 2HN
England; Valideus Limited, a company registered in England and
Wales with company number 06181291 and registered office at 28-30
Little Russell Street, London, WC1A 2HN England; Demys Limited, a
company registered in Scotland with company number SC197176,
having its registered office at 33 Melville Street, Edinburgh,
Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and
Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600,
McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company
registered in Japan having its registered office at Suite
319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further
information see
<a href="https://comlaude.com" target="_blank"
moz-do-not-send="true">www.comlaude.com</a>
</blockquote>
</body>
</html>