ICANN/GNSO GNSO Email List Archives

[council]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: POLICY vs. IMPLEMENTAION (was [council] FW: Letter from the GAC regarding IOC/RC Protections)

  • To: Jonathan Robinson <jonathan.robinson@xxxxxxxxxxx>, "council@xxxxxxxxxxxxxx" <council@xxxxxxxxxxxxxx>
  • Subject: Re: POLICY vs. IMPLEMENTAION (was [council] FW: Letter from the GAC regarding IOC/RC Protections)
  • From: Marika Konings <marika.konings@xxxxxxxxx>
  • Date: Fri, 30 Nov 2012 09:58:17 -0800
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • In-reply-to: <00ec01cdcee7$e9dffbf0$bd9ff3d0$@ipracon.com>
  • List-id: council@xxxxxxxxxxxxxx
  • Sender: owner-council@xxxxxxxxxxxxxx
  • Thread-index: Ac3PJEkL/diuold/RT+mtYa7vOzwXg==
  • Thread-topic: POLICY vs. IMPLEMENTAION (was [council] FW: Letter from the GAC regarding IOC/RC Protections)
  • User-agent: Microsoft-MacOutlook/14.2.5.121010

In relation to tighter linking of policy and implementation, it may be
worth pointing out that in the context of the revised GNSO PDP, there is
already earlier involvement and co-ordination at a staff level to try and
provide input at earlier stages of the PDP with regard to
'implementability'. In addition, the revised PDP foresees the option for
the GNSO Council to create an Implementation Review Team 'to assist Staff
in developing the implementation details for the policy'. The idea is that
the Implementation Review Team, which consists of members of the WG that
developed the policy recommendations, assists ICANN Staff in the
development of the implementation plan and is available to address any
questions or clarifications staff may have. The PDP Manual also foresees
that 'if the proposed implementation is considered inconsistent with the
GNSO Council¹s recommendations, the GNSO Council may notify the Board and
request that the Board review the proposed implementation. Until the Board
has considered the GNSO Council request, ICANN Staff should refrain from
implementing the policy, although it may continue developing the details
of the proposed implementation while the Board considers the GNSO Council
request'. The concept of an Implementation Review Team has already been
used for the PEDNR Recommendations and is also foreseen for the recently
adopted IRTP Part C recommendations.

With best regards,

Marika

On 30/11/12 02:46, "Jonathan Robinson" <jonathan.robinson@xxxxxxxxxxx>
wrote:

>
>All,
>
>This has really kicked off a critical area of discussion and required
>development, as Jeff highlighted at the outset.  At the absolute minimum,
>it
>is great to see the level of engagement in the topic.
>
>A related concept that I do not believe we have yet picked up on in this
>thread, is not around the definition but the sequencing of policy and
>implementation.
>
>It seems that we have often focussed strongly on policy and then
>subsequently followed up with focus on implementation as though they are
>necessarily sequential.
>It reminds me of the current trend in software and systems development
>where
>iterative development with small cycles is very much in fashion now, so
>called Agile Development practices.
>This approach is nowadays often favoured over the more classical
>sequential,
>cascading ("Waterfall" approach) which may produce results which are no
>longer fully relevant to requirements or dated from the outset.
>
>This tighter linking of policy and implementation issues throughout the
>process is certainly something I have heard Fadi mention and I believe it
>is
>on the agenda of ICANN staff to be focussed on and aware of.
>Clearly, the "implementation" of the TMCH and other critical new gTLD
>issues
>has brought this home to Fadi and many if not all of us.
>
>Jonathan
>
>-----Original Message-----
>From: owner-council@xxxxxxxxxxxxxx [mailto:owner-council@xxxxxxxxxxxxxx]
>On
>Behalf Of Volker Greimann
>Sent: 30 November 2012 09:41
>To: joy@xxxxxxx
>Cc: Neuman, Jeff; Jonathan Robinson; council@xxxxxxxxxxxxxx
>Subject: Re: POLICY vs. IMPLEMENTAION (was [council] FW: Letter from the
>GAC
>regarding IOC/RC Protections)
>
>
>All,
>
>I am in full agreement that a better definition of these terms is
>necessary
>and I appreciate staffs efforts in this matter, even though I think this
>needs broader community involvement. Definitely a session to attend in
>Beijing, so I would urge staff not to schedule it concurrently with other
>important sessions. One further consideration is the question if policy
>"taints" (for lack of a better word; I mean it without the negative
>connotations here) implementation. I would argue that even if a decision
>is
>90% implementation and 10% policy, it should be enveloped under the
>umbrella
>of policy and therefore subject to GNSO approval.
>
>Best,
>
>Volker
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi Jonathan and thanks for forwarding this.
>> Jeff, this is an interesting idea which I've asked for comments on
>> from our constituency group.
>> I think it is a good idea to take a step back from the issues and look
>> strategically at what is happening and why in the GNSO relationship
>> with the GAC. The examples you cite are symptoms, I agree, of a wider
>> problem and they will simply keep happening if not resolved. I'm not
>> convinced getting agreed definitions of "policy" vs "implementation"
>> will resolve some of these issues. But if it is a measure to assist
>> and has community support then the Council should consider it.
>> Thanks for raising this
>> Kind regards
>> Joy
>>
>> On 30/11/2012 3:55 a.m., Neuman, Jeff wrote:
>>> All,
>>>
>>>
>>>
>>> We have a very serious problem here that needs immediate attention.
>>> I am not referring to the merits of whether any of these
>>> organizations deserve protection or not, or whether there should be
>>> additional safeguards for IP owners in the new gTLD process or
>>> whether certain Whois Review team recommendations could be put into
>>> place .  Forget all of that.  Forget the merits and substance of
>>> these important issues.
>>>
>>>
>>>
>>> The real issue is that new reliance on the terms ³policy² vs.
>>> ³implementation.²  This is the issue that should receive top
>>> priority. To quote Alan Greenberg (or at least paraphrase), when one
>>> group wants something in place without using the policy process, they
>>> call it ³implementation.²  Those that oppose it, call it ³policy.²
>>> While that statement was made several times by Alan partly in jest,
>>> that statement does have merit.
>>>
>>>
>>>
>>> Lets look at the following 3 examples:
>>>
>>>
>>>
>>> 1.       _ IOC/RC_­ As the letter sent around by Jonathan shows,
>>> the GAC is thoroughly annoyed with the GNSO for starting a policy
>>> process on the protection of IOC and Red Cross marks.  They believe
>>> (although unstated), that they have exclusive jurisdiction over these
>>> types of public policy issues and do not want the GNSO to take
>>> ³years² to work out whether these organizations (which they believe
>>> are protected by law) should receive protections in the new gTLD
>>> process.  Without commenting on the merits of this argument, look at
>>> what they have done. They have called the protections as nothing more
>>> than ³implementation² and therefore, the GNSO should explain itself
>>> as to why we believe we have a right to start a policy process on it.
>>> After all, implementation can just be enacted by the Board.  There is
>>> no need for the GNSO to get involved, in their view?nor do they want
>>> it.
>>>
>>>
>>>
>>> 2.       _Whois Review Team_:  The ICANN Board sought guidance from
>>> the entire Internet community on whether the recommendations involved
>>> ³implementation² or ³policy².  Why? Because if it is implementation,
>>> there is no need to involve the GNSO community and it can just be
>>> enacted.  Those that supported the recommendations wholeheartedly
>>> called them ³implementation.²  Those that opposed the recommendations
>>> called it ³policy.²  I believe that many who called it policy
>>> actually truly believe there are policy issues involved, but some
>>> called it policy, to have it go through the long drawn out process we
>>> call a PDP (with the hopes that it dies a slow death).  Neither side
>>> of this debate is blameless.
>>>
>>>
>>>
>>> 3.       _The now infamous New gTLD ³straw-man²_:  For the record,
>>> I was a part of the group that discussed the straw man in Brussels
>>> and LA over the past few weeks.  I found those discussions very
>>> useful and appreciate the efforts being made by the new ICANN CEO,
>>> who I have a tremendous amount of respect for.  I believe he truly
>>> will make a huge positive impact on ICANN for many years to come.
>>> But, now the debate has turned into what is policy and what is
>>> implementation.  The IPC/BC and their representatives have called
>>> all of their proposals ³implementation².   The NCSG, Registries,
>>> Registrars and Applicants have called much of it policy.  ICANN staff
>>> has now weighed in on their thoughts and have classified certain
>>> items as implementation (thereby negating the need for GNSO policy
>>> development), and other items as policy, thereby requiring extensive
>>> involvement from the GNSO community ­ note I did NOT say necessarily
>>> PDP).
>>>
>>>
>>>
>>> I believe we all need to take a step back from the issues
>>> _immediately_ and decide once and for all an agreed upon bottom-up
>>> multi-stakeholder definition of what is ³policy² and what is
>>> ³implementation.²  Or at the very least a framework for making that
>>> assessment when issues arise.  I would advocate for a cross community
>>> group made up of members from ICANN staff, the GNSO, the GAC and
>>> others to come together to figure this issue out, so that we get out
>>> of this rut we are now in.  At the same time, we need to fix the
>>> image of the GNSO policy processes so that they are no longer feared,
>>> but embraced.  They need to not be used as vehicles for delay, but
>>> rather utilized for the common good.
>>>
>>>
>>>
>>> If we are able to do this, I believe many of the issues we are now
>>> having will become easier to resolve (and we can focus on the
>>> merits). If not, I see these issues getting much worse over the
>>> coming months/years.  I believe the future of the GNSO, and even the
>>> multi-stakeholder model in general hinge on the definition of these 2
>>> words.
>>>
>>>
>>>
>>> I would be very happy to volunteer to serve on such a group.
>>>
>>>
>>>
>>> Thanks.
>>>
>>>
>>>
>>>
>>>
>>> *Jeffrey J. Neuman** **Neustar, Inc. / Vice President, Business
>>> Affairs*
>>>
>>>
>>>
>>> *From:*owner-council@xxxxxxxxxxxxxx
>>> [mailto:owner-council@xxxxxxxxxxxxxx] *On Behalf Of *Jonathan
>>> Robinson *Sent:* Thursday, November 29, 2012 5:00 AM *To:*
>>> council@xxxxxxxxxxxxxx *Subject:* [council] FW: Letter from the GAC
>>> regarding IOC/RC Protections
>>>
>>>
>>>
>>> All,
>>>
>>>
>>>
>>> FYI.  Please see the attached letter received from the GAC last night
>>> my time.
>>>
>>>
>>>
>>> Jonathan
>>>
>>>
>>>
>>> *From:*GAC Secretariat [mailto:gacsec@xxxxxxxxxxxxx] *Sent:* 28
>>> November 2012 21:38 *To:* jonathan.robinson@xxxxxxxxxxx
>>> <mailto:jonathan.robinson@xxxxxxxxxxx> *Cc:* Steve Crocker; Fadi
>>> Chehade; Heather Dryden; Maria Häll; alice@xxxxxxx
>>> <mailto:alice@xxxxxxx>; Choon Sai LIM (IDA) *Subject:* Letter from
>>> the GAC regarding IOC/RC Protections
>>>
>>>
>>>
>>> Sent on behalf of Heather Dryden, GAC Chair
>>>
>>>
>>>
>>> Dear Jonathan,
>>>
>>>
>>>
>>> Attached please find a letter from the GAC regarding IOC and Red
>>> Cross/Red Crescent protections.
>>>
>>>
>>>
>>> Best regards,
>>>
>>>
>>>
>>> Jeannie Ellers
>>>
>>>
>>>
>>> Jeannie Ellers Manager, GAC Coordination Internet Corporation for
>>> Assigned Names and Numbers 1101 New York Avenue NW, Suite 930
>>>
>>> Washington, DC 20005 Ph. +1 202 570 7135 M. +1 310 302 7552
>>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.9 (MingW32)
>> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>>
>> iQEcBAEBAgAGBQJQuCLfAAoJEA9zUGgfM+bq2UYIALFsC+nao4XbcAJOAQn8MKC1
>> 9bkXt7+nH68krEvF7ApfgUrO5JIHX9lEFHS25NSS/tq0KW003dp96WNL0QmVoQPj
>> aqn7NWlplQkVY57eBeF7QxUYwum4jZencdtcpIrpAySPa8uk+jBY9sx/nlxVoNYE
>> 8HbLfTlxPr0leeZ9BdZb8oqxzCmr4WpjTGw/UYMxHPEf8fEptkHFHgEQEty9rpyo
>> eSNQnnbjPHPvoliM8rUSfUca1VpFGNYVJJc9Di5I6xNY3Zar4OX0YmTEyD20j7uc
>> 41nCb8yn8RWfgYHCcY4fURxOs5NDuv+JedrFq7Jbil8KBAkiFoAwoJxeJYPQm5A=
>> =i1KX
>> -----END PGP SIGNATURE-----
>
>
>--
>Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
>
>Mit freundlichen Grüßen,
>
>Volker A. Greimann
>- Rechtsabteilung -
>
>Key-Systems GmbH
>Im Oberen Werk 1
>66386 St. Ingbert
>Tel.: +49 (0) 6894 - 9396 901
>Fax.: +49 (0) 6894 - 9396 851
>Email: vgreimann@xxxxxxxxxxxxxxx
>
>Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com /
>www.BrandShelter.com
>
>Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
>www.facebook.com/KeySystems
>www.twitter.com/key_systems
>
>Geschäftsführer: Alexander Siffrin
>Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.:
>DE211006534
>
>Member of the KEYDRIVE GROUP
>www.keydrive.lu
>
>Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen
>Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder
>Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese
>Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per
>E-Mail oder telefonisch in Verbindung zu setzen.
>
>--------------------------------------------
>
>Should you have any further questions, please do not hesitate to contact
>us.
>
>Best regards,
>
>Volker A. Greimann
>- legal department -
>
>Key-Systems GmbH
>Im Oberen Werk 1
>66386 St. Ingbert
>Tel.: +49 (0) 6894 - 9396 901
>Fax.: +49 (0) 6894 - 9396 851
>Email: vgreimann@xxxxxxxxxxxxxxx
>
>Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com /
>www.BrandShelter.com
>
>Follow us on Twitter or join our fan community on Facebook and stay
>updated:
>www.facebook.com/KeySystems
>www.twitter.com/key_systems
>
>CEO: Alexander Siffrin
>Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
>
>Member of the KEYDRIVE GROUP
>www.keydrive.lu
>
>This e-mail and its attachments is intended only for the person to whom it
>is addressed. Furthermore it is not permitted to publish any content of
>this
>email. You must not use, disclose, copy, print or rely on this e-mail. If
>an
>addressing or transmission error has misdirected this e-mail, kindly
>notify
>the author by replying to this e-mail or contacting us by telephone.
>
>
>
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature



<<< Chronological Index >>>    <<< Thread Index >>>