zh

跨社群工作组:在尊重支持组织/咨询委员会职责的同时鼓励董事会提出建议

2013 年 09 月 18 日
作者: David OliveDavid Olive

作者:David Olive,政策开发支持副总裁

跨社群工作组(简称”CCWG”)在ICANN框架中起着重要的作用。在过去的工作中,我们看到ICANN社群设立的这类工作组是用以组织跨越两个或多个ICANN社群工作时的一种有效机制。

这类合作组织的一个范例是促进引入顶级国际化域名(IDN)的工作组。该工作组启动了在某一国家和地区代码空间内分配有限数量的顶级国际化域名的快速通道流程。另一个例子是域名系统安全性和稳定性分析工作组。

有些跨社群的工作组设立得并不成功,实际上它们甚至在参与其中的支持组织(SO)和咨询委员会(AC)之间造成了混淆和误解。然而,支持组织和咨询委员会之间日益增强的合作,以及在某些问题上取得的成就则惠及了多个支持组织和咨询委员会,从而使得人们加大了对跨社群工作组的关注。

社群中的许多成员都认识到了跨社群工作组给问题讨论所带来的价值,但同时,就这类工作组的运作原则和流程,人们也提出了许多质疑和关切。

跨社群工作组是由来自不同支持组织/咨询委员会的成员在自愿的基础上组建的工作组,以应对他们关注的某一具体问题,该问题影响着ICANN组织结构中的多个关键利益主体团体。1 根据章程,跨社群工作组是由两个或多个支持组织/咨询委员会的成员构成,并在其已获批准的章程中列明了其正式的授权职责。

为什么要组建跨社群工作组呢?

跨社群工作组旨在向与其相关的ICANN组织结构中的支持组织和咨询委员会提供建议和反馈意见。相应的支持组织和咨询委员会则需评估跨社群工作组提出的建议,并确定是否将这些建议正式提交给董事会。

区别任何潜在非正式的沟通与正式的授权职责是至关重要的,工作组章程则明确提出了这类工作组运作的清晰范围。例如,章程中应当预见到当支持组织/咨询委员会不支持跨社群工作组的建议,或希望对其建议进行修改时,应当如何处理。

跨社群工作组最好用于应对可以从跨社群讨论和对话中获益的一些主题,并谨记,这类工作组永远都不能代替正式的政策制定流程。跨社群工作组邀请来自支持组织/咨询委员会的所有社群成员为ICANN内部与社群相关的问题出谋划策。跨社群工作组是多样化的,代表并考量多种利益和纪律,为达成一致意见创造机会。

目前,ccNSO正在使用这种方法来解释国家和地区代码运营商授权和再授权的现行政策。从定义上来说,这一问题属于ccNSO的政策制定的范围。然而,ccNSO则选择组建一个跨社群工作组来做为一种替代方式—考虑到这种方式并不会影响正式的政策建议—从而使得现行政策实现更大的透明度,并确保政府咨询委员会和其他主要利益主体团体能够对此出谋划策并参与进来。

还须考虑的问题、仍须处理的事务

但是,不可以将跨社群工作组视为制定”共识政策”的一种新方式,或将其视为替代现有支持组织和咨询委员会职责的一个机构。跨社群工作组应被视为在应对超越支持组织/咨询委员会工作范围的问题时,用于加强跨社群对话和理解的一种额外机制。

重要的是,从一开始跨社群工作组的职权和运营就应是清晰明确的,因此对其的期望也应是透明而可预见的。为此,GNSO—从其角度—制定了一套拟定原则,以强调跨社群工作组的任何或全部工作职责。这些原则已经在广泛的社群中得以分享,并根据从ccNSO获得的反馈意见,GNSO将在与其他支持组织和咨询委员会合作的同时,在这方面进行更多的工作。

希望这类工作最终将促成跨社群工作组的共同运作原则的形成。根据确定的结构和范围,日后将出现越来越多的跨社群工作组,进一步细分支持组织/咨询委员会的职能,进一步促进多利益主体模型的发展。

ICANN仍将继续探求进一步定义并使用跨社群工作组的方式,以确保它们能够给予有益的贡献,并同时保持对每个支持组织和咨询委员会的尊重,进一步加强自下而上的多利益主体政策制定流程。在此,我敦促各位就这一话题分享自己的看法和建议,请直接对本博文进行评论,或关注问责制和透明度审核小组2就这个问题提出的建议2。积极踊跃的社群参与将确保我们对跨社群工作话题的讨论更具建设性和有效性。


1 ICANN框架中的跨社群工作组:ICANN通用名称支持组织(GNSO)的讨论文件 [PDF文件,149 KB]

2  最近我被邀请就这个问题与ATRT2展开讨论。如需参考我对这个问题的看法,请查看:ATRT2讨论 [PDF文件,105 KB]

Authors

David Olive

David Olive

SVP, Policy Development Support & Managing Director – Washington, D.C.
Read biographyRead biography