<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi All,</p>
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 <i><b>can </b></i><i><b>raise </b></i><i><b>Policy
issues, Implementation issues and Policy/Implementation
borderline issues. </b></i><i><b>But my question is who
decides what category these questions (from all these Sources)
fall into? </b></i>Someone has to look at a question and
decide whether is it policy, implementation or borderline
(implementation, with substantial policy implications).
<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.</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). <br>
</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. <br>
</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.<br>
</p>
<p>Best, Kathy</p>
<div class="moz-cite-prefix">On 5/7/2019 4:05 PM, Aikman-Scalese,
Anne wrote:<br>
</div>
<blockquote type="cite"
cite="mid:397a8cb1860d4b3e9b54d843b9975c46@lrrc.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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
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;}
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;}
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;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
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.EmailStyle29
{mso-style-type:personal-reply;
color:#1F497D;}
.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:#1F497D">Dear WG
members:<o:p></o:p></span></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:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></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”.<o:p></o:p></b></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></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). <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Anne<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"
moz-do-not-send="true"><span style="color:#1F497D"><o:p> </o:p></span></a></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 class="moz-txt-link-freetext" href="mailto:gnso-newgtld-wg-bounces@icann.org">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 class="moz-txt-link-abbreviated" href="mailto:gnso-newgtld-wg@icann.org">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;color:black">[EXTERNAL]</span></strong><span
style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:black"><o:p></o:p></span></p>
<div class="MsoNormal" style="text-align:center"
align="center"><span
style="font-size:12.0pt;font-family:"Times New
Roman",serif">
<hr width="100%" size="2" 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;color:black"
lang="EN-GB">Jeffrey J. Neuman</span></b><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black"
lang="EN-GB"><br>
Senior Vice President<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black"
lang="EN-GB">Com Laude | Valideus<br>
</span></b><span
style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black"
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<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-family:"Arial",sans-serif;color:black"
lang="EN-GB"> <o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:8.0pt;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"
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.
<o:p></o:p></span></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">
<hr width="100%" size="2" align="center">
</span></div>
<p class="MsoNormal"><span
style="font-size:12.0pt;font-family:"Times New
Roman",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> <o:p></o:p></span></p>
</div>
<br>
<hr>
<font size="1" face="Arial" 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>
</font>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Gnso-newgtld-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Gnso-newgtld-wg@icann.org">Gnso-newgtld-wg@icann.org</a>
<a class="moz-txt-link-freetext" href="https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg">https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg</a></pre>
</blockquote>
</body>
</html>