Re: [gnso-policyimpl-wg] Latest version of the comment review document

[Olévié Kouami <olivierkouami@xxxxxxxxx>]

Well done everybody.
Cheers !
-Olévié-


2015-04-08 16:36 GMT+02:00 Gomes, Chuck <cgomes@xxxxxxxxxxxx>:

>  I am not advocating a test run but I am not opposed to one either if the
> circumstances seemed right.  Like I think I said in another message, it
> seems to me that it would be better to use the draft GIP process than to
> use a new ad-hoc process if the GIP fit the need.
>
>
>
> Chuck
>
>
>
> *From:* Michael Graham (ELCA) [mailto:migraham@xxxxxxxxxxx]
> *Sent:* Tuesday, April 07, 2015 6:32 PM
> *To:* Gomes, Chuck; Amr Elsadr; gnso-policyimpl-wg@xxxxxxxxx
> *Subject:* RE: [gnso-policyimpl-wg] Latest version of the comment review
> document
>
>
>
> Great point, Chuck.  And this might be a good answer if we're asked about
> the efficacy of the proposed processes by GNSO (i.e. "Let's try it out if
> you Councillors have a concern with the workability of our proposals.").
> But I wouldn't want to suggest a try before submitting Final Report and
> Recommendations to Council.  Not sure if this was what you were thinking or
> if you were suggesting a "test run".
>
>
>
> *Michael R. Graham*
>
> *Senior Corporate Counsel, Intellectual Property*
>
> *Expedia Legal & Corporate Affairs*
>
> *T* +1 425.679.4330 *|* *F* +1 425.679.7251
>
> *M* +1 425.241.1459
> Expedia, Inc.
> 333 108th Avenue NE *|* Bellevue *|* WA 98004
> *MiGraham@xxxxxxxxxxx <MiGraham@xxxxxxxxxxx>*
>
> CONFIDENTIALITY NOTICE: This electronic message may contain private,
> confidential, and privileged material for the sole use of the intended
> recipient. Any review, copying, or distribution of this message by others
> is strictly prohibited. If you are not the intended recipient, please (i)
> contact the sender immediately; and (ii) permanently delete the original
> and any copies of the message including file attachments.  Thank you for
> your cooperation.
>
>
>
>
>
> *From:* owner-gnso-policyimpl-wg@xxxxxxxxx [
> mailto:owner-gnso-policyimpl-wg@xxxxxxxxx
> <owner-gnso-policyimpl-wg@xxxxxxxxx>] *On Behalf Of *Gomes, Chuck
> *Sent:* Tuesday, April 07, 2015 11:45 AM
> *To:* Amr Elsadr; gnso-policyimpl-wg@xxxxxxxxx
> *Subject:* RE: [gnso-policyimpl-wg] Latest version of the comment review
> document
>
>
>
> Can I agree with everyone?  J
>
>
>
> This has been a great discussion and in my opinion it is excellent proof
> of the quality of the participation that occurs in this WG.  Thanks to all
> of you for your thoughtful comments.
>
>
>
> Let me just share one personal thought.  I think it would be okay to do a
> test of the GIP process if there is a case where it might be useful even
> before it is formally approved as a process as long as it was clear that it
> is simply a test of a process that has not yet been officially approved.  I
> don't think that would be much different than using ad-hoc process as is
> currently done.  I would add though that I think that would probably be
> more problematic for the GGP and EPDP because those processes have some
> binding implications.
>
>
>
> Chuck
>
>
>
> *From:* owner-gnso-policyimpl-wg@xxxxxxxxx [
> mailto:owner-gnso-policyimpl-wg@xxxxxxxxx
> <owner-gnso-policyimpl-wg@xxxxxxxxx>] *On Behalf Of *Amr Elsadr
> *Sent:* Tuesday, April 07, 2015 1:25 PM
> *To:* gnso-policyimpl-wg@xxxxxxxxx
> *Subject:* Re: [gnso-policyimpl-wg] Latest version of the comment review
> document
>
>
>
> Hi,
>
>
>
> I agree with Marika and Michael, but may have read less into what Anne was
> suggesting. I don't think it was her intent to suggest that they processes
> be used before this WG's recommendations are endorsed by the G-Council and
> adopted by the ICANN Board. Seems to me that she only (rightly) pointed out
> an area where the processes that we are developing may be of particular
> usefulness. I certainly agree with that.
>
>
>
> On the other hand, I don't share the concern that others may have
> regarding these processes never being put to good use. In my humble
> experience, I believe that there have been numerous occasions in the not
> too distant past where useful solutions like the ones we've come up with
> would have made things a lot easier for the GNSO Council to do its work.
> This isn't exclusive to GAC Advice either. Specification 13 of the RA is
> one issue that comes to mind -- where the ICANN Board specifically asked for
> GNSO feedback on something impacting gTLD policy development.
>
>
>
> I don't see why there should be a concern about this WG's recommendations
> not being effectively used, when there is a clear and practical need for
> them as tools at the GNSO's disposal.
>
>
>
> Am I missing something?
>
>
>
> Thanks.
>
>
>
> Amr
>
>
>
> On Apr 7, 2015, at 6:42 PM, Marika Konings <marika.konings@xxxxxxxxx>
> wrote:
>
>
>
> To add to Michael's message, I do believe the idea was to include a couple
> of use cases in the Final Report which would show how these processes could
> work in practice, but I had thought that for those use cases we would use
> some of the examples the WG reviewed for which the GNSO Council had used
> ad-hoc processes in the past, but I guess we could also point to
> initiatives that are currently under development.
>
>
>
> Best regards,
>
>
>
> Marika
>
>
>
> *From: *"Michael Graham (ELCA)" <migraham@xxxxxxxxxxx>
> *Date: *Tuesday 7 April 2015 18:38
> *To: *Marika Konings <marika.konings@xxxxxxxxx>, "J. Scott Evans" <
> jscottevans@xxxxxxxxxxx>, "Aikman-Scalese, Anne" <aaikman@xxxxxxxxxx>,
> 'Amr Elsadr' <aelsadr@xxxxxxxxxxx>, "gnso-policyimpl-wg@xxxxxxxxx" <
> gnso-policyimpl-wg@xxxxxxxxx>
> *Subject: *RE: [gnso-policyimpl-wg] Latest version of the comment review
> document
>
>
>
> From a practical/procedural standpoint, I would agree with Marika that we
> could utilize an annotation to the GAC Communique, pointing out possible
> New Processes that could be utilized, to illustrate the usefulness and
> applicability of the proposed processes.  And I agree with her reluctance
> to press these forward as processes that SHOULD be used when they have not
> been reviewed/approved by Counsel.  I am afraid this would make the Final
> Proposal the subject of procedural objection before it could be considered
> and approved as establishing new processes for GNSO consideration.
>
>
>
> Cart and Horse question, I think.
>
>
>
> *Michael R. Graham*
>
> *Senior Corporate Counsel, Intellectual Property*
>
> *Expedia Legal & Corporate Affairs*
>
> *T* +1 425.679.4330 *|* *F* +1 425.679.7251
>
> *M* +1 425.241.1459
> Expedia, Inc.
> 333 108th Avenue NE *|* Bellevue *|* WA 98004
> *MiGraham@xxxxxxxxxxx <MiGraham@xxxxxxxxxxx>*
>
> CONFIDENTIALITY NOTICE: This electronic message may contain private,
> confidential, and privileged material for the sole use of the intended
> recipient. Any review, copying, or distribution of this message by others
> is strictly prohibited. If you are not the intended recipient, please (i)
> contact the sender immediately; and (ii) permanently delete the original
> and any copies of the message including file attachments.  Thank you for
> your cooperation.
>
>
>
>
>
> *From:* owner-gnso-policyimpl-wg@xxxxxxxxx [
> mailto:owner-gnso-policyimpl-wg@xxxxxxxxx
> <owner-gnso-policyimpl-wg@xxxxxxxxx>] *On Behalf Of *Marika Konings
> *Sent:* Tuesday, April 07, 2015 9:31 AM
> *To:* J. Scott Evans; Aikman-Scalese, Anne; 'Amr Elsadr';
> gnso-policyimpl-wg@xxxxxxxxx
> *Subject:* Re: [gnso-policyimpl-wg] Latest version of the comment review
> document
>
>
>
> If the idea is to include the GAC communique as an example which could
> make use of these processes at a future stage, I don't have any issue with
> that. My concern is about recommending now to the GNSO Council the use of
> these processes (or by Dublin) as Anne references in her email before these
> are finalised and approved by the WG, GNSO Council and ICANN Board.
>
>
>
> Best regards,
>
>
>
> Marika
>
>
>
> *From: *"J. Scott Evans" <jscottevans@xxxxxxxxxxx>
> *Date: *Tuesday 7 April 2015 18:26
> *To: *Marika Konings <marika.konings@xxxxxxxxx>, "Aikman-Scalese, Anne" <
> aaikman@xxxxxxxxxx>, 'Amr Elsadr' <aelsadr@xxxxxxxxxxx>, "
> gnso-policyimpl-wg@xxxxxxxxx" <gnso-policyimpl-wg@xxxxxxxxx>
> *Subject: *RE: [gnso-policyimpl-wg] Latest version of the comment review
> document
>
>
>
> I don't see why we could "recommend" that these processes be used, perhaps
> as an example.  Are we concerned that, by doing so, we might create a
> situation whereby the negative reaction would be such that the processes
> would never be put to such good use?  I am confused as to why we can't
> "recommend" something that we thing improves the GNSO procedures. Isn't
> that the whole point of the exercise in the first place?
>
>
> *j. scott evans - associate general counsel - adobe - 408.536.5336
> <408.536.5336> - jscottevans@xxxxxxxxxxx <jscottevans@xxxxxxxxxxx>*
>  ------------------------------
>
> From: marika.konings@xxxxxxxxx
> To: jscottevans@xxxxxxxxxxx; aaikman@xxxxxxxxxx; aelsadr@xxxxxxxxxxx;
> gnso-policyimpl-wg@xxxxxxxxx
> Subject: Re: [gnso-policyimpl-wg] Latest version of the comment review
> document
> Date: Tue, 7 Apr 2015 16:22:44 +0000
>
> Until the WG recommendations are finalised and approved both by the GNSO
> Council and ICANN Board, I don't think it would be appropriate for the WG
> to recommend that the response to the GAC communique should refer to these
> processes. I don't doubt that once the WG recommendations are adopted and
> implemented they may be very useful in guiding this work, but I don't think
> it would be prudent to make recommendations on the basis of processes that
> have not been finalised nor adopted yet.
>
>
>
> Best regards,
>
>
>
> Marika
>
>
>
> *From: *"J. Scott Evans" <jscottevans@xxxxxxxxxxx>
> *Date: *Tuesday 7 April 2015 18:13
> *To: *"Aikman-Scalese, Anne" <aaikman@xxxxxxxxxx>, 'Amr Elsadr' <
> aelsadr@xxxxxxxxxxx>, "gnso-policyimpl-wg@xxxxxxxxx" <
> gnso-policyimpl-wg@xxxxxxxxx>
> *Subject: *RE: [gnso-policyimpl-wg] Latest version of the comment review
> document
>
>
>
> I think Anne is making some solid points here.
>
>
>
>
> *j. scott evans - associate general counsel - adobe - 408.536.5336
> <408.536.5336> - jscottevans@xxxxxxxxxxx <jscottevans@xxxxxxxxxxx>*
>  ------------------------------
>
> From: AAikman@xxxxxxxxxx
> To: aelsadr@xxxxxxxxxxx; gnso-policyimpl-wg@xxxxxxxxx
> Subject: RE: [gnso-policyimpl-wg] Latest version of the comment review
> document
> Date: Tue, 7 Apr 2015 01:34:06 +0000
>
> Amr et al,
>
> Perhaps what I am saying is that the WG could recommend that in responding
> to GAC Communiques to the Board and using the tool that Amr showed us, the
> Council could identify one of the three processes as an appropriate method
> of addressing each of the issues e.g. a notation such as "GNSO Council to
> address via GIP, or "to address via GGP" or "to address via EPDP" or GNSO
> Council considers a full PDP is required to address this issue" or "GNSO
> Council believes this issue was already addressed via PDP - see Final
> Report of X Working Group Paragraph Y".
>
>
>
> The point here is the same that Greg is making.    The GAC Communique is
> exactly the type of communication that should trigger consideration of
> these new processes by the GNSO and so it would indeed be handy for the
> Council to consider this possibility in relation to the form being
> developed for response to GAC Communiques.
>
>
>
> The suggestion was definitely not that ONE of the new processes would be
> suitable for response to the GAC. The suggestion was rather that the GNSO
> Council could, in responding to the GAC Communique that is sent to the
> Board, state that intends to use one of the new tools to foster GNSO Input
> (GIP) or Guidance (GGP) or Policy Development (EPDP) to respond to the
> GAC's advice.  These three options are of course NOT exclusive since
> Council is free to respond however it may want to respond to GAC
> communiques.  However, we are trying to standardize processes and build
> trust and as Greg notes, it would be a shame if the processes were
> recommended, adopted, and then never actually used.
>
>
>
> I think it is clear that the timeline will not permit use of these
> processes to be listed in a response to the Singapore meeting, but it does
> seem that they could be incorporated down the line and hopefully no later
> than the Dublin communique  (as a goal in terms of time frames.)
>
> Anne
>
>
>
> *<image001.gif>*
>
> *Anne E. Aikman-Scalese, Of Counsel*
>
> *Lewis Roca Rothgerber LLP |*
>
> *One South Church Avenue Suite 700 | Tucson, Arizona 85701-1611*
>
> *(T) 520.629.4428 <520.629.4428> | (F) 520.879.4725 <520.879.4725>*
>
> *AAikman@xxxxxxxxxx <AAikman@xxxxxxxxxx>* *| www.LRRLaw.com
> <http://www.lrrlaw.com/>*
>
>
>
>
>
>
>
> *From:*owner-gnso-policyimpl-wg@xxxxxxxxx [
> mailto:owner-gnso-policyimpl-wg@xxxxxxxxx
> <owner-gnso-policyimpl-wg@xxxxxxxxx>] *On Behalf Of *Amr Elsadr
> *Sent:* Wednesday, April 01, 2015 4:28 PM
> *To:* gnso-policyimpl-wg@xxxxxxxxx
> *Subject:* Re: [gnso-policyimpl-wg] Latest version of the comment review
> document
>
>
>
> Hi,
>
>
>
> My personal impression is that the the Council's approach so far on
> providing feedback on GAC communiqués has been more about the GNSO Council
> simply communicating to the ICANN Board (and GAC) where the GNSO stands on
> any given Advice item -- how it has been, or is being, dealt with. It is
> more of a discussion on a Council process to address GAC Advice on
> GNSO-related work, rather than a GNSO process. The processes this WG is
> recommending are initiated following a request to the GNSO to do so. The
> process being discussed by the Council is initiated following GAC Advice to
> the Board, not the GNSO. This template currently being envisioned as a tool
> to that end may be helpful in understanding this a little more:
> http://gnso.icann.org/en/drafts/review-gac-communique-24feb15-en.pdf
>
>
>
> However, none of that is to say that a result of one of these templates
> from the GNSO Council to the ICANN Board (and cc'd to the GAC) could not
> result in either the Board or the GAC requesting that the GNSO initiate a
> process to explore the issue at hand. That could very likely be a
> possibility, and one of the processes being developed here could come in
> handy in a situation like this. I wouldn't go so far as to suggest that
> only one of the processes would be suitable. I guess it would depend on
> what questions the GNSO is trying to answer.
>
>
>
> In any case, I would be happy, in my capacity as one of the Council
> liaisons to this WG, to relay any message the WG Chairs or members would
> like to have communicated to the Council on this matter.
>
>
>
> Thanks.
>
>
>
> Amr
>
>
>
> On Apr 2, 2015, at 12:32 AM, Greg Shatan <gregshatanipc@xxxxxxxxx> wrote:
>
>
>
> It might be an interesting exercise to discuss these mechanisms
> specifically with the Council, given that these are being created for the
> Council to use, in a sense.  I think we also anticipate that the Council
> would use one of these mechanism for any sort of GNSO policy utterance,
> unless it was wholly unsuited to the purpose.  Our work would be a waste if
> we created these mechanisms and the Council went on its merry way making up
> ad hoc response processes, while neglecting our creations like a set of
> gift golf clubs in the closet.
>
>
>
> Greg
>
>
>
> On Wed, Apr 1, 2015 at 2:48 PM, Aikman-Scalese, Anne <AAikman@xxxxxxxxxx>
> wrote:
>
> Thanks Mary.  As far as I know, although Council is aware of our work,
> there has been no specific discussion of the possibility of reacting to GAC
> communiques within the suggested framework of using these tools.
>
> Thank you,
>
> Anne
>
>
>
> *<image001.gif>*
>
> *Anne E. Aikman-Scalese, Of Counsel*
>
> *Lewis Roca Rothgerber LLP |*
>
> *One South Church Avenue Suite 700 | Tucson, Arizona 85701-1611*
>
> *(T) 520.629.4428 <520.629.4428> | (F) 520.879.4725 <520.879.4725>*
>
> *AAikman@xxxxxxxxxx <AAikman@xxxxxxxxxx>* *| www.LRRLaw.com
> <http://www.lrrlaw.com/>*
>
>
>
>
>
>
>
> *From:* Mary Wong [mailto:mary.wong@xxxxxxxxx]
> *Sent:* Wednesday, April 01, 2015 11:38 AM
> *To:* Gomes, Chuck; Aikman-Scalese, Anne; 'Carlos Raúl Gutiérrez'
> *Cc:* Marika Konings; gnso-policyimpl-wg@xxxxxxxxx
>
>
> *Subject:* Re: [gnso-policyimpl-wg] Latest version of the comment review
> document
>
>
>
>
>
> Hello everyone - just to note that the GNSO Council has been discussing a
> possible approach for the provision of GNSO feedback pertaining to issues
> that may be raised or impacted by points made in GAC Communiques. Note
> that, since the GAC provides its advice via Communique directly to the
> Board, the Council's discussions have largely centered on developing a
> structured method of providing GNSO input to the Board as well.
>
>
>
> It may be that the GIP could be an appropriate mechanism for some items in
> the future, but we thought this WG might like to know that the Council is
> also discussing this specific topic (while also aware of the
> recommendations our group is making).
>
>
>
> Thanks and cheers
>
> Mary
>
>
>
> Mary Wong
>
> Senior Policy Director
>
> Internet Corporation for Assigned Names & Numbers (ICANN)
>
> Telephone: +1 603 574 4892
>
> Email: mary.wong@xxxxxxxxx
>
>
>
>
>
> *From: *<Gomes>, Chuck <cgomes@xxxxxxxxxxxx>
> *Date: *Wednesday, April 1, 2015 at 14:29
> *To: *"Aikman-Scalese, Anne" <AAikman@xxxxxxxxxx>, 'Carlos Raúl
> Gutiérrez' <crg@xxxxxxxxxxx>
> *Cc: *Marika Konings <marika.konings@xxxxxxxxx>, "
> gnso-policyimpl-wg@xxxxxxxxx" <gnso-policyimpl-wg@xxxxxxxxx>
> *Subject: *RE: [gnso-policyimpl-wg] Latest version of the comment review
> document
>
>
>
>  Thanks for the good feedback Anne.  The clarification on the GAC
> communiques makes sense.
>
>
>
> Chuck
>
>
>
> *From:* Aikman-Scalese, Anne [mailto:AAikman@xxxxxxxxxx
> <AAikman@xxxxxxxxxx>]
> *Sent:* Wednesday, April 01, 2015 2:08 PM
> *To:* Gomes, Chuck; 'Carlos Raúl Gutiérrez'
> *Cc:* Marika Konings; gnso-policyimpl-wg@xxxxxxxxx
> *Subject:* RE: [gnso-policyimpl-wg] Latest version of the comment review
> document
>
>
>
> Hi Chuck,
>
> I would defer to Amr on the question of the proposed change in language
> about GNSO challenges to implementation measures.  We should also see what
> Alan, Cheryl, Carlos, and others have to say, however.
>
>
>
> Regarding reaction to GAC communiques, I was not suggesting that one of
> the new processes be deployed to respond.   I was suggesting that when the
> GAC identifies implementation issues in its communique, the GNSO should
> determine on an issue-by-issue basis ( and advise the Board in writing)
> whether it can treat the GAC concerns best by
>
> 1. Not responding or responding that the issue was already treated
> thoroughly in a PDP.
>
> 2. Responding that IRT and staff should deal with the issue
>
> 3. Initiating a GIP
>
> 4. Initiating a GGP or
>
> 5. Initiating an EPDP.
>
>
>
> I just think it would be very helpful for GNSO to put each of the GAC
> issues in one of these "buckets" because very often it is a GAC communique
> that triggers the need for issue resolution - and very often there is time
> pressure on the issue for one reason or another.
>
>
>
> Thank you,
>
> Anne
>
>
>
> *<image001.gif>*
>
> *Anne E. Aikman-Scalese, Of Counsel*
>
> *Lewis Roca Rothgerber LLP |*
>
> *One South Church Avenue Suite 700 | Tucson, Arizona 85701-1611*
>
> *(T) 520.629.4428 <520.629.4428> | (F) 520.879.4725*
>
> *AAikman@xxxxxxxxxx <AAikman@xxxxxxxxxx>* *| www.LRRLaw.com
> <http://www.lrrlaw.com/>*
>
>
>
>
>
>
>
> *From:* Gomes, Chuck [mailto:cgomes@xxxxxxxxxxxx <cgomes@xxxxxxxxxxxx>]
> *Sent:* Tuesday, March 31, 2015 4:44 PM
> *To:* Aikman-Scalese, Anne; 'Carlos Raúl Gutiérrez'
> *Cc:* Marika Konings; gnso-policyimpl-wg@xxxxxxxxx
> *Subject:* RE: [gnso-policyimpl-wg] Latest version of the comment review
> document
>
>
>
> Thanks very much for the very thoughtful comments.  Please see my
> responses below.
>
>
>
> Chuck
>
>
>
> *From:* Aikman-Scalese, Anne [mailto:AAikman@xxxxxxxxxx
> <AAikman@xxxxxxxxxx>]
> *Sent:* Tuesday, March 31, 2015 1:14 PM
> *To:* 'Carlos Raúl Gutiérrez'; Gomes, Chuck
> *Cc:* Marika Konings; gnso-policyimpl-wg@xxxxxxxxx
> *Subject:* RE: [gnso-policyimpl-wg] Latest version of the comment review
> document
>
>
>
> Carlos and Chuck,
>
> I have been following this thread to some degree and wanted to make some
> comments before tomorrow's call:
>
>
>
> 1.      I do not think that the WG proposals expand GNSO "discretionary
> powers" in any way.  As I understand it, we are simply providing more
> standardized mechanisms for providing GNSO input and
> policy-making/implantation  processes so that the processes that get
> followed are not so "ad hoc" (as were those that we studied at the
> beginning of our work).  In my view, increasing the standardization of the
> processes will lead to more trust in the community.  In other words, these
> processes themselves create "checks and balances" in the system (per
> Carlos' comment) because it is assumed that one of the three standard
> processes will in fact fit the changed circumstances or need to address
> issues during the implementation phase.  As we all know, some of these
> "changed circumstances" arise due to late-breaking facts (e.g. name
> collision) or to late-breaking advice (e.g. in the case of the GAC.)  Our
> assumption must be that these things will occur and we need to be prepared
> to address them in a systematic fashion as they arise.
>
> *[Chuck Gomes] Makes sense to me but I would be surprised (and pleased) if
> the one of the three processes covered all changed circumstances.*
>
>
> 2.      Per my comments on the last call, I still think the WG should not
> continue to pretend that only the GNSO makes policy.  One need only look at
> issues like GAC Safeguards, IGO/NGO, and two letter registrations at the
> second level to develop a full appreciation of how policy really works in
> ICANN.  GNSO is the primary policy-making body but the policy GNSO makes is
> a matter of recommendations.  If this were not so, there would not be a
> provision in the By-Laws which states that there is a Board voting
> threshold for acting against a GNSO policy recommendation.  We are not
> going to change this through the efforts of our WG because we cannot stop
> the special position of GAC advice under the By-Laws or stop the fact that
> governments legislate and SOs and Committees other than the GAC do not make
> binding laws.  Then there is the fact that certain groups, e.g. ALAC, do
> not have a vote on the GNSO, but certainly have the ability to influence
> policy and make policy recommendations directly to the Board (e.g. with
> respect to a letter to the Board recommending  "freezing" certain gTLDs
> that carry higher consumer risk.)  Either the WG is recommending processes
> in which the entire community can participate or it is acting in a GNSO
> "vacuum".  I had thought the intent of our WG was to supply work that would
> be helpful to the entire community.  (Thus, I do not like the suggested
> RySG proposed change in principles which states that the *GNSO* reserves
> the right to challenge implementation, rather than the principle that the
> community reserves the right to challenge implementation.  Based on the new
> standardized procedures we are recommending, any other body within ICANN
> should be able to bring an issue to the GNSO in order to initiate a
> challenge.  It would be a great result if the GAC ultimately decided to
> pursue one of its issues through a GNSO process.  (They may say I'm a
> dreamer.)
>
> *[Chuck Gomes] Did you see the compromise language I proposed on the RySG
> recommendation?  I didn't test it with the RySG but I think it would
> accomplish what was intended in the suggested change.  The RySG did not
> intend the change from 'community' to 'GNSO' to mean that community members
> outside of the GNSO could not contribute but rather to reflect the fact
> that the GNSO is responsible for gTLD policy work and hence should be
> responsible for challenging any implementation steps that it believes is
> beyond what was intended in the policy.  That said, I am not prepared to
> fight hard for the change.*
>
>
> 3.      I agree that "separation of powers" is one reason the WG was
> formed.  The community reacted to the fact that it was unwilling to let the
> ICANN Board and staff determine implementation issues that might raise
> policy considerations.  Then the WG determined that if there are issues
> during implementation, what is most important is NOT how the issue is
> characterized, but rather, does ICANN itself have efficient means of
> dealing with issues as they arise?   This is the underlying logic for the
> three mechanisms that are being proposed.
>
> *[Chuck Gomes] If separation of powers means that policy development power
> is separated from policy implementation power, then I don't agree.  The
> GNSO is responsible for developing policy recommendations and for ensuring
> that those recommendations are implemented appropriately.  I don't think
> that that responsibility should be delegated to staff without GNSO
> oversight.  I do agree though that the three processes we have proposed are
> designed to provide ways of dealing with issues as they arise.*
>
>
>
> 4.      With respect to working out issues that arise during
> implementation with other bodies within ICANN that influence policy enacted
> by the ICANN Board, the need for greater coordination has certainly been
> recognized.  For example, Mason is now the GAC liaison and there is a trial
> program in place for involving the GAC early on in the PDP Issue Scoping
> phase (see notes from March 19 GNSO Council meeting).  Our WG should also
> be looking at how best to involve the GAC (and other non-GNSO voting
> bodies) in the three new processes that are being recommended.  For
> example, right now the GNSO is developing a "template" for response to the
> Singapore GAC communique.  I am watching this and saying to myself - this
> is EXACTLY why we need the standardized processes we have been working on.
> To my mind, in the future, the GNSO should be using the GIP or the GGP or
> the EPDP to respond to the GAC Communiques and advising the Board which of
> these processes should be used with respect to each issue raised by the GAC
> communique.
>
> *[Chuck Gomes] In my opinion, the GIP could be a good tool for this.  It
> is less clear that the GGP would work very well and I definitely do not
> think that the EPDP would fit.  Both would probably take too long and the
> Council needs to respond to the GAC in a timely manner.  And I don't think
> the EPDP restrictions would be applicable in most cases of GAC communiques,
> but I would be happy to be proven wrong.*
>
>
>
> I look forward to our continuing discussions and like all of you, am
> hopeful that these recommendations can actually make the ICANN policy AND
> implementation process function more smoothly, thereby increasing trust in
> the DNS both inside and outside the community.
>
>
>
> Anne
>
>
>
> *<image001.gif>*
>
> *Anne E. Aikman-Scalese, Of Counsel*
>
> *Lewis Roca Rothgerber LLP |*
>
> *One South Church Avenue Suite 700 | Tucson, Arizona 85701-1611*
>
> *(T) 520.629.4428 <520.629.4428> | (F) 520.879.4725*
>
> *AAikman@xxxxxxxxxx <AAikman@xxxxxxxxxx>* *| www.LRRLaw.com
> <http://www.lrrlaw.com/>*
>
>
>
>
>
>
>
> *From:*owner-gnso-policyimpl-wg@xxxxxxxxx [
> mailto:owner-gnso-policyimpl-wg@xxxxxxxxx
> <owner-gnso-policyimpl-wg@xxxxxxxxx>] *On Behalf Of *Carlos Raúl Gutiérrez
> *Sent:* Monday, March 30, 2015 1:27 PM
> *To:* Gomes, Chuck
> *Cc:* Marika Konings; gnso-policyimpl-wg@xxxxxxxxx
> *Subject:* Re: [gnso-policyimpl-wg] Latest version of the comment review
> document
>
>
>
> Dear Chuck,
>
>
>
> sorry but i was away from my PC this morning and could not go back to the
> GGP/GIP/EPDP definitions. My answer to your last question is basically yes:
>
>
>
>    - There should a clearer argument why this requests go back to the
>    original source, and not to higher (appellate?) instance, and
>    - Why it differs from the review a redress path (is it for speed?
>    cost? else?) that is being thoroughly reviewed somewhere else right now
>    - There should be a minimum threshold of the arguments for the
>    request, explaining why is there need for the clarification, and not just
>    another run at trying to change decisions in retrospect. And it should come
>    from affected parties directly.
>    - The threshold should increase from GGP to GIP, and even more to
>    EPDP. I'm afraid there will be more controversy with the last one.
>    - Are the groups proposed to deal with all this GGP/GIP/EPDP work be
>    sustainable over time, representative of the community, or do they risk to
>    be captured by other parts of the system, so the can delegate their
>    responsibility?
>    - There should also be a recognition that the world became much more
>    complex, with the jump form 30 to a 1'000 Domain Names, and that the GNSO
>    is not going to be the solving all issues that will arise in the future,
>    PARTICULARLY if the GDD or the Compliance functions have NOT done there
>    work in a proper manner. And don't get me wrong here, the separation of
>    power i'm talking about is "horizontal" between the different steps in the
>    policy to contract to business process
>    - If there is a (what I would call a ) "vertical" problem between GNSO
>    and Board as you mention, then a pdp will not solve it
>
>
>
> To put it in a nutshell, my impression is that we need a clearer and
> compelling argument ready to the question that will certainly pop up at
> some point: If the GNSO did his work right in the first place, why do we
> need this new stuff???
>
>
>
> And here the length of the document does not cover lack of the background
>  you know so well,  but newbies like me with just 5 years in the backbench
> don't fully understand. And you are right on another thing: I didn't like
> the survey questionnaire. Just by agreeing to all individual elements, can
> we automatically can assume the whole effort is on solid ground. Economists
> get burned easily by marginal analysis that looks only at the cost of the
> last unit produced.
>
>
>
> Thank you very much
>
>
>
> Carlos Raúl Gutiérrez
> _____________________
>
> email: crg@xxxxxxxxxxx
> Skype: carlos.raulg
> +506 8335 2487 (cel)
> +506 4000 2000 (home)
> +506 2290 3678 (fax)
> _____________________
> Apartado 1571-1000
>
> San Jose, COSTA RICA
>
>
>
>
>
>
>
>
>
>
>
>  On Mar 30, 2015, at 1:19 PM, Gomes, Chuck <cgomes@xxxxxxxxxxxx> wrote:
>
>
>
> Am I correct Carlos that in referring to the mechanisms you mean the GNSO
> Guidance Process (GGP), GNSO Input Process (GIP) and the Expedited PDP
> (EPDP)?  If so, the descriptions of each of those processes explains who
> can initiate them.  Do you think that more information is needed?  If so,
> specific suggestions would be helpful.
>
>
>
> If I understand correctly, I agree with you that requests for initiation
> of one the three processes should be accompanied with a strong case.  That
> would then allow the GNSO Council to make the best decision possible as to
> whether or not to initiate one of them.  Of course, several of the
> questions we asked in the request for comments survey relate to that.
>
>
>
> Chuck
>
>
>
> *From:* Carlos Raúl G. [mailto:crg@xxxxxxxxxxx <crg@xxxxxxxxxxx>]
> *Sent:* Monday, March 30, 2015 12:12 PM
> *To:* Gomes, Chuck
> *Cc:* Marika Konings; gnso-policyimpl-wg@xxxxxxxxx
> *Subject:* Re: [gnso-policyimpl-wg] Latest version of the comment review
> document
>
>
>
>
>
> Carlos Raúl Gutiérrez
>
> +506 8837 7176 (New Number)
>
> Enviado desde mi iPhone
>
>
> El mar 30, 2015, a las 9:49, Gomes, Chuck <cgomes@xxxxxxxxxxxx> escribió:
>
>  Carlos,
>
>
>
> I just finished listening to the recording and found it very helpful.
> Thank you for your comments in the meeting and below.  Please see my
> responses inserted below.
>
>
>
> Chuck
>
>
>
> *From:* Carlos Raúl Gutiérrez [mailto:crg@xxxxxxxxxxx <crg@xxxxxxxxxxx>]
> *Sent:* Monday, March 30, 2015 11:02 AM
> *To:* Marika Konings
> *Cc:* Gomes, Chuck; gnso-policyimpl-wg@xxxxxxxxx
> *Subject:* Re: [gnso-policyimpl-wg] Latest version of the comment review
> document
> *Importance:* High
>
>
>
> Dear Chuck
>
>
>
> let me summarize my worries in a few sentences, based on the comments you
> will hear in the recording. While the new mechanisms look very useful and
> elegant in print, I worry about the checks and balances in so far as "who
> triggers them and why". Particularly the third one worries me a lot.
>
>
>
> I come from a very old school of "separation of powers", where one entity
> develops policy, another separate one executes it, and if there is trouble
> they both can go to a third entity to solve their differences. The recent
> letter of Senators Thune and Rubio seems to come from this very same school
> of thought, as they ask for clear organisational and or structural
> separations of functions.
>
> *[Chuck Gomes] In the new TLD program implementation, the position of
> extreme separation of powers that the Board and staff took cause some
> serious problems. Staff and the Board took the position that if an issue
> was implementation, then they could essentially take care of it on their
> own and didn't need to involve the GNSO.  That was a primary reason for the
> creation of the P&I WG.*
>
>
>
> Separation of powers is always good if there is an effective independent
> review and redress mechanism for the Board decision of approving the policy
> in the first place. Agree it does not seem to be the case today.
>
>
>
>
>
> Since the gTLD came into full swing, I could positively see that some kind
> of similar division of powers evolving within ICANN> a separate Division
> *GDD* was created to deal with (and hopefully be responsible) of the new
> contracts and collecting monies, as well as an enforced separate group
> looking at the compliance of those contracts, just to avoid any conflict of
> interest in the GDD with their clients.
>
>
>
> For that reason I believe we should be very careful that the mechanisms
> proposed are used only when there are proven problems downstream, i.e.
> mainly with the GDD and or compliance functions and not to everybody for
> every possible argument.
>
> *[Chuck Gomes] I don't think I understand your point here. What mechanisms
> are you talking about?  The GDD is the body that will be tasked with
> implementation so I understand the reference to the GDD but compliance
> wouldn't come into play directly until after a policy is implemented
> although we might consult with them in policy and implementation work to
> obtain their input as needed.  What do you mean "*that the mechanisms
> proposed are used only when there are proven problems downstream*"?  The
> purpose of our principles and recommendations are to avoid problems in the
> future not to react to problems.*
>
>
>
> For that reason I'm only asking for a very clear explanation of the
> triggers to the consultation
>
>
>
>
>
> If the mechanism  are used within the GNSO at their discretion, without a
> well grounded reason from their execution and compliance point of view,
> they risk to become a closed feedback loop, that may put into question the
> policy development process that initiated the whole issue.
>
> *[Chuck Gomes] Again, I do not understand what you are saying.  What
> mechanisms are you talking about? What closed feedback loop? One of the
> main purposes of the principles and recommendations we are proposing is to
> ensure that the policy development process is not compromised.*
>
>
>
> Sorry I haven't learned by hearth the names of the 3 type s of
> consultations.
>
>
>
> For that reason, my general comments should be seen under my question of
> "who or what, and on what ground triggers those elegant mechanisms", so as
> to avoid the feeling that the GNSO get additional discretionary powers
> trough them. I think this is important in these time of increased awareness
> of Accountability and Transparency.
>
> *[Chuck Gomes] This also is hard to understand because I don't know what
> mechanisms you are talking about.  Also, what do you mean by "*get
> additional discretionary powers*" of the GNSO?*
>
>
>
> If the policy is out and approved by the Board, the revision should be
> triggered outside of the GNSO with ver compelling arguments. I rest my case.
>
>
>
> Happy to continue in the next WG session if I can make it.
>
>
>
> Cheers
>
>
>
> Carlos Raúl Gutiérrez
> _____________________
>
> email: crg@xxxxxxxxxxx
> Skype: carlos.raulg
> +506 8335 2487 (cel)
> +506 4000 2000 (home)
> +506 2290 3678 (fax)
> _____________________
> Apartado 1571-1000
>
> San Jose, COSTA RICA
>
>
>
>
>
>
>
>
>
>
>
>  On Mar 30, 2015, at 1:21 AM, Marika Konings <marika.konings@xxxxxxxxx>
> wrote:
>
>
>
> Hi Chuck,
>
>
>
> Please note that Carlos is a member of the Working Group and participated
> in the last meeting (including providing further feedback on his comments).
> Hopefully he'll be able to join our next meetings as well to be able to
> answer any follow up questions the WG may have.
>
>
>
> We'll fix the template ahead of the next meeting in relation to item 4.18.
>
>
>
> Best regards,
>
>
>
> Marika
>
>
>
> *From: *<Gomes>, Chuck Gomes <cgomes@xxxxxxxxxxxx>
> *Date: *Saturday 28 March 2015 22:40
> *To: *"gnso-policyimpl-wg@xxxxxxxxx" <gnso-policyimpl-wg@xxxxxxxxx>
> *Subject: *[gnso-policyimpl-wg] Latest version of the comment review
> document
>
>
>
> On my flight home from Istanbul, I went through the latest version of the
> comment review document.  Here are some comments and questions I have.
>
>
>
> Who is responsible for performing any action items we identify? Note the
> following action items identified to date:
>
> ·         3.7  and multiple other items- we need further input from
> Carlos; Carlos made a lot of lengthy comments throughout the survey that I
> think would best be resolved via a conversation with him and the WG.  Let's
> talk about this.  Here are the items: 3.7, 4.14, 5.2, 5.11, 5.20, 7.4, 8.4,
> 13.4, 14.3, G.1.
>
> ·         4.1 & other items - This wasn't identified in the action column
> but rather in the response column.  Several of John Poole's comments
> related to the initial error we made in referencing a section of the
> survey.  Did anyone communicate with him on the fact that the error was
> corrected?
>
> ·         4.4 - This wasn't identified in the action column but rather in
> the response column.  We discussed asking the RySG to propose alternative
> language.
>
>
>
> My comments on the items discussed in my absence on 25 March:
>
> ·         4.7 - The RySG comment was noted.  What do others think about
> adding the sentence redlined below?
>
>
>
> *Principle C.2.c):"*Each ofthe principlesin thisdocument
> mustbeconsideredin termsof thedegree towhich theyadheretoandfurther
> theprinciples definedin ICANN'sCore Valuesasdocumentedin article2of
> theICANN by---laws (http://www.icann.org/en/about/governance/bylaws#I).P
> <http://www.icann.org/en/about/governance/bylaws#I%29>articular note
> should be made tocore value4: "Seekingandsupportingbroad,
> informedparticipation reflectingthefunctional,geographic, andcultural
> diversityof theInternet atalllevelsof policydevelopment anddecision---
> making."  (The WG notes that informed communication depends on effective
> communication throughout the community.)
>
>
>
> ·         4.8 - The WG decided to reject the change suggested by the RySG
> from 'community' to 'GNSO' because it was felt that it would narrow the
> scope to exclude affected parties outside of the GNSO from participating.
> I actually think the RySG change is correct because the GNSO is the policy
> management body, not the full community, but I also believe it would be
> good to deal with the issue the WG identified.  What about the following?
>
>
>
> *PrincipleD.1.b: *"Changesto GNSOimplementation guidanceneedtobeexamined
> bythe GNSOCouncil or  anotherappropriate entityasdesignatedby theGNSO
> Councilonwhere theyfall inthe spectrumofpolicyand implementation.In
> allcases, thecommunity*GNSO*maintainsthe rightto challengewhether
> suchupdates needfurtherreviewfor policyimplications while at the same
> time recognizing that all impacted parties in the community should be given
> the opportunity to contribute to the GNSO challenge process.*"*
>
>
>
> ·         4.14 and later substantial comments by Carlos - As I suggested
> toward the beginning of my response, I personally think it might be useful
> and the most time effective to schedule a call with Carlos and the WG or
> some subset of the WG to have a live discussion of his concerns and
> possible solutions.
>
>
>
> The NCSG makes some substantial suggestions on at least 11 items.
> Fortunately, we have some NCSG members in our WG so I think it would be
> good for us to discuss those when the NCSG members can be present.  Here
> are the items: 5.4, 5.22, 5.24, 5.31, 7.6, 8.6, 9.6, 11.6, 13.6, 14.5, G.4.
>
>
>
> Likewise, the ALAC makes some substantial suggestions on at least 4 items.
> Fortunately, we have some ALAC members in our WG so I think it would be
> good for us to discuss those when the ALAC members can be present.  Here
> are the items:  5.5/5.6, 5.15, 5.33, G6.
>
>
>
> And the IPC also makes some substantial suggestions on at least 6items.
> Fortunately, we have some IPC members in our WG so I think it would be good
> for us to discuss those when the IPC members can be present.  Here are the
> items:  7.5, 9.5, 10.5, 12.5, 14.4, G.3.
>
>
>
> Marika & I talked briefly in Istanbul.  We have not made as much progress
> on going through the public comments as we had hoped and may be in jeopardy
> of missing our target dates.  She suggested that we could get some
> volunteers (or small groups of volunteers) to draft possible responses for
> subsets of the items and then present those to the full WG.  Of course we
> would need volunteers for that to work.  How many of you would be willing
> to do this?  In the cases of the comments from the ALAC, IPC and NCSG, we
> would need to pair WG members from those respective groups with some who
> are not from those groups. Please respond to this email if you are willing
> to contribute in this way.  Another option could be to lengthen our calls
> from 60 minutes to 90 minutes; please respond if you could or could not do
> that.
>
>
>
> Marika/Mary - Note that we ended up with a sea pair of duplicate items:
> all of 4.18 appears to be included in 4.19.  I suggest that we delete 4.18
> and leave 4.19.  The fact that this only happened once is pretty remarkable
> considering how much manual entry had to be done.
>
>
>
> Chuck
>
>
>
>
>
>
>
>
>
>
>
>
>  "This message (including any attachments) is intended only for the use
> of the individual or entity to which it is addressed, and may contain
> information that is non-public, proprietary, privileged, confidential and
> exempt from disclosure under applicable law or may be constituted as
> attorney work product. If you are not the intended recipient, you are
> hereby notified that any use, dissemination, distribution, or copying of
> this communication is strictly prohibited. If you have received this
> message in error, notify sender immediately and delete this message
> immediately."
>
>
>
>
>  ------------------------------
>
>
> 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.
>
>
>  ------------------------------
>
>
> 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.
>
>
>  ------------------------------
>
>
> 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.
>
>
>
>
>
> --
>
> *Gregory S. Shatan **ï* *Abelman Frayne & Schwab*
>
> *Partner** | IP | Technology | Media | Internet*
>
> *666 Third Avenue | New York, NY 10017-5621*
>
> *Direct*  212-885-9253 *| **Main* 212-949-9022
>
> *Fax*  212-949-9190 *|* *Cell *917-816-6428
>
> *gsshatan@xxxxxxxxxxx <gsshatan@xxxxxxxxxxx>*
>
> *ICANN-related: gregshatanipc@xxxxxxxxx <gregshatanipc@xxxxxxxxx>*
>
> *www.lawabel.com <http://www.lawabel.com/>*
>
>
>
>
>  ------------------------------
>
>
> 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.
>
> <image001.gif>
>
>
>



-- 
Olévié Ayaovi Agbenyo KOUAMI
Responsable du Projet CERGI Education
Directeur-Adjoint de KT Technologies Informatiques sarl
SG de ESTETIC  - Association Togolaise des professionnels des TIC (
http://www.estetic.tg)
ICANN-NPOC Communications Committee Chair (http://www.icann.org/ et
http://www.npoc.org/)
Membre du FOSSFA (www.fossfa.net) et Membre de de Internet Society (
www.isoc.org)
BP : 851 - Tél.: (228) 90 98 86 50 / (228) 98 43 27 72
Skype : olevie1 FB : @olivier.kouami.3 Twitter : #oleviek Lomé - Togo