[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 April 2019

Wed May 1 16:33:42 UTC 2019

+1

Thanks,
Mike

Mike Rodenbaugh
RODENBAUGH LAW
tel/fax: +1.415.738.8087
http://rodenbaugh.com

On Tue, Apr 30, 2019, 11:42 PM Austin, Donna via Gnso-newgtld-wg <
gnso-newgtld-wg at icann.org> wrote:

> I know Jeff is interested to hear from others, but unfortunately I’ve
> become confused by the email discussion and can no longer discern what the
> problem is we are trying to solve.
>
>
>
> It would be helpful if the problem could be articulated along with the key
> points of the respective arguments or concerns.
>
>
>
> Thanks
>
>
>
> Donna
>
>
>
> *From:* Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces at icann.org] *On
> Behalf Of *Aikman-Scalese, Anne
> *Sent:* Wednesday, May 01, 2019 12:31 PM
> *To:* Jeff Neuman <jeff.neuman at comlaude.com>; Julie Hedlund <
> julie.hedlund at icann.org>; gnso-newgtld-wg at icann.org
> *Subject:* Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD
> Subsequent Procedures PDP WG - 30 April 2019
>
>
>
> Thanks Jeff. Sorry for the confusion as to which email you were responding
> to on the list.  The EPDP was a process ALREADY IN PLACE in the ICANN
> ByLaws (Annex E) and the GNSO Operating Procedures long before the Temp
> Spec issue arose specifically because the GNSO Policy and Implementation
> Working Group developed it years ago *after the 2012 round launched* and
> put it in place for application at ANY TIME if needed.  That process was
> NOT developed just as a “response to a situation”.    ( Please note that
> Annex IV refers to EPDP, not ePDP and that this process is codified in the
> amendments to the ICANN ByLaws as Annex E which occurred long before the
> Temp Spec issue arose.)
>
>
>
> The same is true of the GNSO Guidance and GNSO Input processes.  These
> processes apply post-launch and were developed with SPECIFIC reference to
> issues that arose post-launch in 2012. Their applicability was not
> restricted to the “next round” pre-launch phase by any stretch of the
> imagination.   No one is saying that ICANN org and IRT have to bring every
> issue in front of GNSO Council.  On the other hand, no one  should be
> trying to use the “Predictability Framework’ to eliminate GNSO oversight
> post-launch as reflected in these established processes.   It is absolutely
> untrue that GNSO has to “check out” once a program launches.  That would be
> very bad policy indeed.
>
>
>
> As a former active member of the Policy and Implementation Working Group,
> I would be happy to discuss your theory that GNSO oversight using these
> processes does not apply after launch in a live update session with GNSO at
> the meeting in Marrakech.  But looking at the plain language,  “  A GIP
> may be initiated by the GNSO Council at any time it considers appropriate
> should contribute to our understanding.
>
>
>
> Anne
>
>
>
> *From:* Jeff Neuman [mailto:jeff.neuman at comlaude.com
> <jeff.neuman at comlaude.com>]
> *Sent:* Tuesday, April 30, 2019 7:08 PM
> *To:* Aikman-Scalese, Anne <AAikman at lrrc.com>; Julie Hedlund <
> julie.hedlund at icann.org>; gnso-newgtld-wg at icann.org
> *Subject:* Re: Notes and Action Items - New gTLD Subsequent Procedures
> PDP WG - 30 April 2019
>
>
>
> *[EXTERNAL]*
> ------------------------------
>
> Anne
>
>
>
> For clarification, I did not remove any text in my reply.  If you look
> back, my reply was to your first email (that did not have the citations),
> not to your e-mail to Kathy, which did have the citations.
>
>
>
> First of all I appreciate the discussion on the word "generally".  Truth
> is I drafted that language off-the cuff to be illustrative and not as
> definitive language to use.  But it sounds like the concept of stating that
> this new entity (whatever we call it) will follow those rules helps to
> clarify certain things.  That's progress!
>
>
>
> Comparing the ePDP on the Temp Spec to this is like apples and oranges.
> It doesn't relate.  The ePDP did not come out of the launch of a program
> derived from a process that was started by the GNSO and implemented by an
> IRT.  The ePDP was a response to proposed mechanisms created by ICANN staff
> to respond to an external legal situation.  The GNSO Council then believed
> this mechanism involved a change to previous Consensus Policies and then
> launched the ePDP.
>
>
>
> In this case, we have our PDP which will be followed by implementation of
> the policies derived from this Working Group and implemented by ICANN staff
> with the help of an IRT.  Then the new gTLD program will launch.  Once it
> launches, if there is truly a proposed change that would implicate policy,
> then the GNSO can (and should) initiate the normal GNSO processes as the
> Council deems appropriate.  The Standing New gTLD Advisory Group (formerly
> "standing IRT") would not have a role.  This would clearly be the case if
> ICANN wanted to change material portions of the legal agreement, or change
> a rule like allowing/not allowing closed generics, etc.
>
>
>
> But for the more minor changes, the ones that do not implicate policy or
> even implementation (but rather implicate execution), the GNSO processes do
> not address these situations and they can be way to bureaucratic to
> handle.  For example,take ICANN's decision to change Digital Archery to a
> Random Drawing, or it changes the mechanics of the Pre-delegation testing.
> There was NO policy or even implementation process that was impacted and
> therefore arguably No role for the GNSO.  But there were no processes to
> deal with those changes at all and ICANN therefore shot from the hip.  It
> announced the changes, but did not solicit feedback from the impacted
> parties.  It was a disaster from a predictability standpoint.  The
> Predictability Framework attempts to deal with this a create a predictable
> process where none exists.
>
>
>
> I know you are arguing that the GNSO processes do account for these, but I
> and much of the community disagree with your view.  We cannot invoke an
> ePDP or even GNSO input process for these types of issues.  We cannot just
> tell ICANN they cant do anything that deviates at all even if circumstances
> necessitate changes. *But we do need to have a predictable framework to
> deal with these.*
>
>
>
>  Lets hear from others please.
>
>
>
>
>
>
>
> *Jeff Neuman*
>
> Senior Vice President
>
>
> *Com Laude | Valideus *1751 Pinnacle Drive
>
> Suite 600, McLean
>
> VA 22102, USA
>
>
> M: +1.202.549.5079
>
> D: +1.703.635.7514
>
> E: *jeff.neuman at comlaude.com <jeff.neuman at comlaude.com>*
> www.comlaude.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.comlaude.com_&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=XR09DCK81pDSR2hF6lgR1uioa2Ve81ZdgQNkcu1E1v4&e=>
>
>
> ------------------------------
>
> *From:* Aikman-Scalese, Anne <AAikman at lrrc.com>
> *Sent:* Tuesday, April 30, 2019 9:39 PM
> *To:* Jeff Neuman; Julie Hedlund; gnso-newgtld-wg at icann.org
> *Subject:* RE: Notes and Action Items - New gTLD Subsequent Procedures
> PDP WG - 30 April 2019
>
>
>
> Jeff,  please don’t delete portions of my comments or cites to text from
> the Operating Procedures when you reply to my input.  When you do, that
> makes things difficult for those who are only reading from the latest
> message and scrolling down.  Thank you in advance for respecting this
> request.
>
>
>
> It is helpful that you suggest that the newly named entity would abide by
> the same GNSO  rules and procedures as an IRT.  Not sure why your statement
> is conditioned upon the word “generally” or why you would call it anything
> other than a “Post-Launch IRT”.   The word “generally” leaves too much
> wiggle room when the WG solicited public comment on a “Standing IRT”.  If
> you call it a “Post-Launch Standing IRT”, you eliminate ALL confusion and
> you don’t’ have to use the word “generally” or go out for more public
> comment if you have Consensus.  (You also don’t have to create a new ICANN
> acronym that no one understands unless they have been on this Working
> Group.)
>
>
>
> Regarding our disagreement as to the time frame for applicability of the
> GNSO Annexes, I don’t see any references to “pre-launch” and “post-launch”
> in the Consensus Policy Implementation Framework (CPIF) or any references
> to new issues that arise post-launch.   The only reference in the CPIF is
> to “Policy Effective Date”.  The new recommendation in the Initial Report
> would modify the CPIF because it would provide for a Standing IRT
> post-launch.   *Please note the CPIF states the IRT has to be briefed on
> the GNSO Input and GNSO Guidance processes and this same briefing should be
> required for  any Post-Launch IRT in order to ensure GNSO oversight is in
> place post-launch.  (Thus my conclusion that there is too much wiggle room
> in your use of the word  “generally”.)*
>
>
>
> Obviously the GNSO Annexes for further Council work apply at any time,
> including post-launch. Otherwise, how could GNSO have possibly initiated
> and conducted an EPDP on the Temp Spec when that Annex came out of the same
> recommendations?  In this regard, please note that the three processes
> specifically refer to “new issues”.    *Hopefully you are not suggesting
> that GNSO Council loses its oversight authority or ability to avail itself
> of these Input and Guidance processes after an application window opens?*
>
>
>
> See again the highlighted language below from GNSO Guidance and GNSO Input
> Annexes which states, for example,  as to GNSO Input that a “ *GIP MAY BE
> INITIATED BY THE GNSO COUNCIL AT ANY TIME IT CONSIDERS APPROPRIATE*”.
>   - PLEASE DON’T DELETE THIS LANGUAGE OR THE HIGHLIGHTED PORTION OF THE
> TEXT FROM THE MANUALS WHEN YOU REPLY:
>
>
>
> GNSO Input Process Manual -
> https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-3-input-process-manual-18jun18-en.pdf
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_default_files_file_field-2Dfile-2Dattach_annex-2D3-2Dinput-2Dprocess-2Dmanual-2D18jun18-2Den.pdf&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=bzWrxmspMkeDJwJLq86fMSW_IyuAZP_F7XyBcgTfta0&e=>
>
>
>
> *GNSO Input Process (GIP) Introduction*:   A GIP is the process through
> which the GNSO provides input on matters that may not involve gTLD policy,
> for example in response to a request from the ICANN Board or in response to
> a public comment forum as further described in this GIP Manual. Any such
> requests should include as much information as possible. A GIP may be
> initiated by the GNSO Council at any time it considers appropriate, for
> example, when a request for GNSO input is received from the ICANN Board or
> other entity that does not involve the creation of new obligations for
> ICANN contracted parties and does not relate to a topic otherwise suitable
> for a GNSO Policy Development Process or GNSO Guidance Process, for example
> providing GNSO Input to a public comment forum.
>
>
>
> GNSO Guidance Manual -
> https://gnso.icann.org/sites/default/files/file/field-file-attach/annex-5-ggp-manual-18jun18-en.pdf
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_default_files_file_field-2Dfile-2Dattach_annex-2D5-2Dggp-2Dmanual-2D18jun18-2Den.pdf&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=PQxaL7Lv7CpEbUNA5DhB18eORlzFL-2BJO3wQhoaFDQ&e=>
>
>
>
>
>
> *GNSO Guidance Process Manual**1.GGP Manual –Introduction*:  These
> guidelines and processes supplement the requirements for GGPs described in
> Annex D of the ICANN Bylaws [include link]. A GGP may be initiated by the
> GNSO Council when a request for input relating to gTLDs (either a new
> issue or in relation to previous policy recommendations) has been
> received from the ICANN Board or a gTLD issue has been identified by the
> GNSO Council that would benefit from GNSO Guidance, and it has determined
> that the intended outcome of the GGP is not expected to create new
> “Consensus Policy” recommendations including, but not limited to, any new
> contractual obligations for contracted parties (in which case a PDP would
> need to be initiated). However, the GGP may provide interpretation or
> assist in providing clarity with regards to the implementation of GNSO
> policy recommendations. The GGP should not be used as a tool to reopen a
> previously explored policy issue only because a constituency or stakeholder
> group was not satisfied with outcome of a previously held process on the
> same policy issue, unless the circumstances have changed and/or new
> information is available
>
>
>
> Anne
>
>
>
>
>
> Anne
>
>
>
> *From:* Jeff Neuman [mailto:jeff.neuman at comlaude.com
> <jeff.neuman at comlaude.com>]
> *Sent:* Tuesday, April 30, 2019 5:50 PM
> *To:* Aikman-Scalese, Anne <AAikman at lrrc.com>; Julie Hedlund <
> julie.hedlund at icann.org>; gnso-newgtld-wg at icann.org
> *Subject:* Re: Notes and Action Items - New gTLD Subsequent Procedures
> PDP WG - 30 April 2019
>
>
>
> *[EXTERNAL]*
> ------------------------------
>
> Please see my comments in red below.
>
>
>
> *From:* Aikman-Scalese, Anne <AAikman at lrrc.com>
>
>
>
> *[Anne] Initial Report and Public Comment.* The Initial Report
> recommended a "Standing IRT". There is a common understanding in the ICANN
> community about what an IRT does, how it is constituted, and what its
> powers are and are not.  The documentation in GNSO procedures lays out the
> rules re IRT, including the composition of such a team which requires broad
> representation across the community.  These understandings are codified in
> the GNSO Council Operating Procedures and in the Consensus Policy
> Implementation Framework. If the proposed body is renamed, this would
> require additional public comment which would include the need to specify
> how such a body would be constituted and what is powers would be.
>
>
>
> [Jeff] I do not agree that simply changing the name of the body would
> require additional public comment.  In fact we could state in the report
> something to the effect of:  "Because of the confusion caused between the
> term we used in the Initial Report, and how that term is generally used to
> describe a team responsible for the implementation of GNSO policies, we
> have changed the name to the "Standing New gTLD Advisory Group" (SNAG).
> Though we have changed the name, this new group should abide by the same
> rules and procedures generally applicable to Implementation Review Teams as
> set forth in existing GNSO Procedures".
>
>
>
> Why would that not solve the issue?
>
>
>
> *[Anne] Effect on Existing GNSO Procedures and ICANN ByLaws.*  Once you
> apply a new name to this proposed new body designed specifically to address
> implementation issues post-launch, you have an animal that is not
> recognized in the Consensus Policy Implementation Framework nor in the GNSO
> Input, Guidance, and EPDP processes and is thus not incorporated into the
> language of those processes.  Therefore, you will either have created a
> need for massive redrafting (including redrafting of the ICANN ByLaws) OR
> you will have removed that new body from the application of those
> processes. Jeff says there is no intention to change the applicability of
> the GNSO Input, Guidance, and EPDP process post-launch so it does not
> really make sense to name a new type of team that would require significant
> changes to existing procedures (and maybe even the ByLaws.) Thus, a "name
> change" for this body creates more questions than it answers.
>
>
>
> [Jeff]  Applying the same language above would fix all of this. We are not
> modifying any existing process.
>
>
>
> *[Anne] Prior Work of the Policy and Implementation WG.*  This has been a
> long-standing issue in Sub Pro since Leadership initially took the position
> that the GNSO Input, Guidance, and EPDP processes do not apply after
> launch.  This is categorically not true.
>
>
>
>
>
> [Jeff]  I know this has been your argument all along, but the
> documentation does not support your view.  See
> https://www.icann.org/policy/implementation
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_policy_implementation&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=fGYI02A0z8Rt2vMHDzRZO89Z15edVRNF23fgudLvYDk&e=>
>  and https://www.icann.org/uploads/ckeditor/CPIF_v2.0_2019CLEAN.pdf
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_uploads_ckeditor_CPIF-5Fv2.0-5F2019CLEAN.pdf&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=uY4fujh1pLZJcb3MVAFVqis1l-Y_dtm637IAO4OPRrI&e=>.
> These all show that the IRT's work is prior to the Policy Effective Date.
> For the new gTLD process, that would be the day that the application window
> launches.  I don't see anything that supports your view.
>
>
>
> [Anne] The Policy and Implementation Working Group examined numerous
> examples of issues that arose “post-launch” in the 2012 round.   We
> ultimately concluded it is fruitless to try to characterize issues as
> either “policy” or “implementation” since one person’s policy is another’s
> implementation and vice versa. The mechanisms that were developed after
> the 2012 round to address these issues were specifically developed to apply
> WHENEVER the issue arise and to keep control of the issues at GNSO Council
> in a very transparent manner. It would be a massive change of policy to
> offer a new construct that either (1) causes the results of that PDP to
> have to be amended or (2) creates a new body that operates outside the
> established procedures already adopted by the Board and the GNSO.
>
>
>
> [Jeff] I dont disagree that distinguishing between policy and
> implementation is difficult.  But this Predictability Framework does not
> change anything regarding transparency or any existing process.
>
>
>
> *[Anne] If everyone is anxious to simply clarify the time period in which
> the Team will operate, why not just call the teams the “Pre-launch IRT” and
> the “Post-launch IRT”.  Much simpler and more predictable – and requires a
> lot less redrafting.*
>
>
>
> *[Jeff] For the reasons above, I do not share the view that calling
> something a Pre-Launch or a Post Launch IRT will clear up the confusion or
> require much re-drafting.*
>
>
>
> *Lets see what others in the group think.*
>
>
>
>
>
> *Jeff Neuman*
>
> Senior Vice President
>
>
> *Com Laude | Valideus *1751 Pinnacle Drive
>
> Suite 600, McLean
>
> VA 22102, USA
>
>
> M: +1.202.549.5079
>
> D: +1.703.635.7514
>
> E: *jeff.neuman at comlaude.com <jeff.neuman at comlaude.com>*
> www.comlaude.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.comlaude.com_&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=XR09DCK81pDSR2hF6lgR1uioa2Ve81ZdgQNkcu1E1v4&e=>
>
>
> ------------------------------
>
> *From:* Aikman-Scalese, Anne <AAikman at lrrc.com>
> *Sent:* Tuesday, April 30, 2019 5:36 PM
> *To:* Julie Hedlund; gnso-newgtld-wg at icann.org
> *Cc:* Jeff Neuman
> *Subject:* RE: Notes and Action Items - New gTLD Subsequent Procedures
> PDP WG - 30 April 2019
>
>
>
> Regarding yesterday's call and the attempt to measure consensus on the
> recommendation for a “Standing IRT”, changing the name of that recommended
> body actually creates more confusion rather than less.  The reasons are:
>
>
>
> *Initial Report and Public Comment.* The Initial Report recommended a
> "Standing IRT". There is a common understanding in the ICANN community
> about what an IRT does, how it is constituted, and what its powers are and
> are not.  The documentation in GNSO procedures lays out the rules re IRT,
> including the composition of such a team which requires broad
> representation across the community.  These understandings are codified in
> the GNSO Council Operating Procedures and in the Consensus Policy
> Implementation Framework. If the proposed body is renamed, this would
> require additional public comment which would include the need to specify
> how such a body would be constituted and what is powers would be.
>
>
>
> *Effect on Existing GNSO Procedures and ICANN ByLaws.*  Once you apply a
> new name to this proposed new body designed specifically to address
> implementation issues post-launch, you have an animal that is not
> recognized in the Consensus Policy Implementation Framework nor in the GNSO
> Input, Guidance, and EPDP processes and is thus not incorporated into the
> language of those processes.  Therefore, you will either have created a
> need for massive redrafting (including redrafting of the ICANN ByLaws) OR
> you will have removed that new body from the application of those
> processes. Jeff says there is no intention to change the applicability of
> the GNSO Input, Guidance, and EPDP process post-launch so it does not
> really make sense to name a new type of team that would require significant
> changes to existing procedures (and maybe even the ByLaws.) Thus, a "name
> change" for this body creates more questions than it answers.
>
>
>
> *Prior Work of the Policy and Implementation WG.*  This has been a
> long-standing issue in Sub Pro since Leadership initially took the position
> that the GNSO Input, Guidance, and EPDP processes do not apply after
> launch.  This is categorically not true.  The Policy and Implementation
> Working Group examined numerous examples of issues that arose “post-launch”
> in the 2012 round.   We ultimately concluded it is fruitless to try to
> characterize issues as either “policy” or “implementation” since one
> person’s policy is another’s implementation and vice versa. The mechanisms
> that were developed after the 2012 round to address these issues were
> specifically developed to apply WHENEVER the issue arise and to keep
> control of the issues at GNSO Council in a very transparent manner. It
> would be a massive change of policy to offer a new construct that either
> (1) causes the results of that PDP to have to be amended or (2) creates a
> new body that operates outside the established procedures already adopted
> by the Board and the GNSO.
>
>
>
> *If everyone is anxious to simply clarify the time period in which the
> Team will operate, why not just call the teams the “Pre-launch IRT” and the
> “Post-launch IRT”.  Much simpler and more predictable – and requires a lot
> less redrafting.*
>
>
>
> Anne
>
>
>
>
>
> *Anne E. Aikman-Scalese*
>
> Of Counsel
>
> 520.629.4428 office
>
> 520.879.4725 fax
>
> AAikman at lrrc.com
>
> _____________________________
>
> Lewis Roca Rothgerber Christie LLP
>
> One South Church Avenue, Suite 700
>
> Tucson, Arizona 85701-1611
>
> lrrc.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lrrc.com_&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=QjIVm7u6qvimxYSvs-pk0vknh4ycARaEWHtYxbqgpoM&e=>
>
>
>
>
>
>
>
>
>
> *From:* Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces at icann.org
> <gnso-newgtld-wg-bounces at icann.org>] *On Behalf Of *Julie Hedlund
> *Sent:* Tuesday, April 30, 2019 8:38 AM
> *To:* gnso-newgtld-wg at icann.org
> *Subject:* [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent
> Procedures PDP WG - 30 April 2019
>
>
>
> *[EXTERNAL]*
> ------------------------------
>
> Dear Working Group members,
>
>
>
> Please see below the notes from the meeting today, 30 April 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:
> https://community.icann.org/display/NGSPP/2019-04-30+New+gTLD+Subsequent+Procedures+PDP
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_display_NGSPP_2019-2D04-2D30-2BNew-2BgTLD-2BSubsequent-2BProcedures-2BPDP&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=Kq9-Q1TqcXzyiOxZOdjPTNNzTi7qJEiptbSsIH4W9v4&e=>.
>
>
>
>
> Please also see the referenced document at:
> https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-w/edit?usp=sharing
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-2Dw_edit-3Fusp-3Dsharing&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=iUz100Ji1JrIGzccYRbuxnvYKRWaET41282e2eHpY9Q&e=>
> .
>
>
>
> Kind regards,
>
> Julie
>
> Julie Hedlund, Policy Director
>
>
>
> *Notes and Action Items:*
>
>
>
> *Action Items:*
>
> -- Staff will check on the ICANN Board response to the GAC advice in the
> Helsinki Communique’ on new gTLDs.
>
> -- WG to come up with a different name for the “standing IRT”.  Maybe
> “Post Application Advisory Team”.
>
>
>
> *Notes:*
>
>
>
> 1. Updates to Statements of Interest: No updates provided.
>
>
>
> 2. Review of Summary Documents – (see:
> https://docs.google.com/document/d/1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-w/edit?usp=sharing
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1R4zXTH3hIgfbqoxyqsSp19Bl6J96NNeV7oCgxsXKD-2Dw_edit-3Fusp-3Dsharing&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=iUz100Ji1JrIGzccYRbuxnvYKRWaET41282e2eHpY9Q&e=>
> )
>
>
>
> 2.2.1 Continuing Subsequent Procedures
>
>
>
> Policy Goals / What the WG is Seeking to Accomplish
>
> -- First bullet: replace “rounds” with “procedures”.
>
>
>
> *2.2.1.c.1*: The Working Group recommends no changes to the existing
> policy calling for subsequent application rounds introduced in an ongoing,
> orderly, timely and predictable manner.
>
> -- Support from most commenters
>
>
>
> New Ideas/Concepts for Deliberations:
>
> -- GAC Advice and BC: Support for new rounds but no rounds started until
> reviews (CCT-RT) are complete.  Need to do a cost-benefit analysis before
> starting new round.
>
> -- WG is taking into consideration the CCT-RT recommendations.
>
>
>
> Discussion:
>
> -- Policy does not have a demand component.
>
> -- Action Item: Board response to GAC Advice in the Helskinki Communique’.
>
> -- Note that the CCT-RT did have an economic study done by the Analysis
> Group, although perhaps not a full cost-benefit analysis.
>
> -- Concerns with maintaining the current policy unless there are
> objections.
>
> -- Unless there is a consensus on changing precedent we should stay on the
> same path.
>
> -- Can build on what we have learned, but hard to do analysis on what
> people might want.
>
> -- If the WG wants to request for an assessment to be done that will have
> to be approved by the Council.
>
> -- Calling for rounds introduced in an ongoing orderly timely and
> predictable manner support came from pretty much every group that responded
> in public comments to the Initial Report.
>
> -- We have some qualifications from the GAC.
>
>
>
> *2.2.1.e.1:* The 2007 Final Report noted that success metrics would be
> developed around the New gTLD Program. What are some specific metrics that
> the program should be measured against?
>
> -- Support from most commenters.
>
>
>
> New Ideas/Concepts for Deliberations: ALAC, BRG, BC, RySG – New Ideas
>
>
>
> Discussion:
>
> -- Good proposals for different types of metrics.
>
> -- Need to define what we mean by success; CCT-RT referred that issue to
> the SubPro WG.
>
> -- Questions and issues in the CCT-RT could put some of these issues to
> rest.
>
> -- This WG could come up with a half dozen categories (elements of the
> program) and develop definitions of success for those – or develop targets,
> which is a less loaded word.
>
> -- Good conversation to continue on email.
>
> -- You could have a high-level structure from the 2012 round (to foster
> diversity, encourage competition, and enhance the utility of the DNS), then
> create specific targets within that structure within that framework.
>
>
>
> 2.2.2 Predictability
>
>
>
> -- Support from most commenters
>
> -- BC/RySG/IPC/ALAC (in response to e.1): New Idea - The Standing IRT must
> be representative of the community, but must also allow for the appointment
> of experts where needed.
>
>
>
> New Ideas/Concepts for Deliberations -- ICANN Org: Concerns/New Ideas
>
>
>
> Discussion:
>
> -- Can things in the model be improved so that you can support it?  If
> not, what takes its place?
>
> -- Don’t think it’s in our authority to replace the GNSO policy process.
>
> -- We're not changing any of the policies or processes that have been
> established.
>
> -- Changes to policies after the launch need to go through the GNSO policy
> process; the predictability framework is for issues that come up outside of
> that process and guidance to the standing IRT.  In the report we called it
> a standing IRT, but that seems to be confusing so we should change the
> name.  Could call it a “gateway” to decide what is policy and what is not,
> and only looking at non-policy issues.
>
> -- Need to be more conscious of the need for predictability for third
> party interests.  We use the term “affected parties” for that reason.
>
> -- WG needs to come up with a different name for the “standing IRT”.
> Maybe a Post Application Advisory Team.
>
>
>
>
> ------------------------------
>
>
> 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.
> ------------------------------
>
> 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 www.comlaude.com
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__comlaude.com&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=Pa0EaR47hJeK-pQPwT4-DtFYXGiu7wwXuW7Wy8ADHGQ&e=>
>
>
> ------------------------------
>
>
> 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.
> ------------------------------
>
> 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 www.comlaude.com
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__comlaude.com&d=DwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=CwipU91YB6EkpFXK9ynnT_QUef4yC5p7jpsDm8cU97g&m=ywU8VjOzJpixDVSuWgH1x2Wyi_mRBxOTFP47QtT_hWM&s=Pa0EaR47hJeK-pQPwT4-DtFYXGiu7wwXuW7Wy8ADHGQ&e=>
>
>
> ------------------------------
>
>
> 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.
> _______________________________________________
> Gnso-newgtld-wg mailing list
> Gnso-newgtld-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20190501/406e601e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 7567 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20190501/406e601e/image001-0001.jpg>