Dear
Councillors,
Please find the updated
agenda for the GNSO Public Council meeting today, 9 March 2016. The main changes
are in the order of the items and the time allotted for each
item.
Proposed
Agenda for the GNSO Council Public Meeting in Marrakech 9 March
2016
This agenda was
established according to the GNSO Council Operating
Procedures, approved and updated
on 24 June 2015.
For convenience:
·
An excerpt of the ICANN
Bylaws defining the voting thresholds is provided in Appendix 1 at the
end of this agenda.
·
An excerpt from the
Council Operating Procedures defining the absentee voting procedures is provided
in Appendix 2 at the end of this agenda.
Coordinated
Universal Time: 13:30 UTC
05:30 Los Angeles; 08:30 Washington; 13:30
London; 15:30 Istanbul; 00:30 Hobart
GNSO Council Meeting Audio
Cast
To join the event click on the link: http://stream.icann.org:8000/gnso.m3u
Councilors should
notify the GNSO Secretariat in advance if they will not be able to attend and/or
need a dial out call.
___________________________________________
Item 1: Administrative
matters (5 minutes)
1.1 – Roll
call
1.2 – Updates to
Statements of Interest
1.3 – Review/amend
agenda.
1.4 – Note the
status of minutes for the previous Council meetings per the GNSO Operating
Procedures:
Minutes of the meeting of the GNSO
Council on 18 February 2016
were posted as approved on 6 March 2016.
Item 2: Opening Remarks
/ Review of Projects & Action List (5 minutes)
2.1 – Review
focus areas and provide updates on specific key themes / topics, to include
review of Projects
List and Action
List
Item 3: Consent agenda
(5 minutes)
3.1 – Approve
appointment of co-chairs for the New gTLD Subsequent Procedures Policy
Development Process Working Group (co-chairs: Stephen Coates, Avri Doria, Jeff
Neuman; Council liaison: Paul McGrady)
Item 4: VOTE – Approval
of Proposed Approach for Implementing Recommendations from the GNSO Review (5
minutes)
As part of ICANN's
Bylaws-mandated periodic review of its structures, the ICANN Board's Structural
Improvements Committee (now known as the Organizational Effectiveness Committee)
appointed Westlake Governance as the independent examiner to conduct the current
review of the performance and operations of the GNSO. A GNSO Working Party,
chaired by former Councillor Jennifer Wolfe and comprising representatives of
all the GNSO's Stakeholder Groups and Constituencies, was formed to consult with
Westlake over the design and conduct of the review. Westlake's Draft Report was
published for public comment on 1 June
2015. Following feedback received, including from the GNSO Working Party,
Westlake published its Final Report on 15 September. The Working
Party reviewed all the recommendations to develop guidance for the GNSO Council
and ICANN Board in relation to the implementability and prioritization of the
recommendations. The Council received a written update from the Working Party chair
on 29 January, and the Working Party’s proposed Implementation and Feasibility Analysis was sent to the
Council on 28 February.
Here the Council will
review the Working Party’s Implementation and Feasbility Analysis, and vote on
its adoption as well as agree on next steps in the
process.
4.1 – Presentation of
the motion (Wolf-Ulrich
Knoben)
4.2 –
Discussion
4.3 – Council vote
(voting threshold: simple majority)
Item 5: COUNCIL VOTE -
Approval of Charter for a PDP Working Group to review all RPMs in all gTLDs (15
minutes)
On 18 February 2016,
the GNSO Council voted unanimously to initiate a new Policy Development Process
(PDP) to review all Rights Protection Mechanisms (RPMs) in all gTLDs (see http://gnso.icann.org/en/council/resolutions#20160218-3).
At that meeting, a small group of Councilors volunteered to review the draft
Charter for the PDP Working Group, with a view to submitting an updated Charter
for the Council’s review and approval at the Marrakech meeting. The draft
Charter had been based substantially on the approach recommended in the Final
Issue Report, published on 11 January 2015 (see http://gnso.icann.org/en/issues/new-gtlds/rpm-final-issue-11jan16-en.pdf).
This recommended that the GNSO Council proceed with a two-phased PDP, with the
first phase focused on a review of the RPMs developed for the New gTLD Program
and the subsequent, second phase on a review of the longstanding Uniform Dispute
Resolution Policy (UDRP). A Working Group Charter typically also sets out the
scope of work for the PDP Working Group and includes a list of topics identified
previously by the community for the Working Group to consider including as part
of its work. Here the Council will consider
the updated draft Charter and vote on its
adoption.
5.1 – Presentation of
the motion (Phil Corwin)
5.2 –
Discussion
5.3 – Council vote
(voting threshold: an affirmative vote of
more than one-third (1/3) of each House or more than two-thirds (2/3) of one
House)
Item 6: VOTE – Approval
of Recommendations from the Cross-Community Working Group on Enhancing ICANN
Accountability (55 minutes)
In the course of
discussions over the IANA stewardship transition, the community had raised
concerns about ICANN's accountability, given ICANN's historical contractual
relationship with the United States government. The community discussions
indicated that existing ICANN accountability mechanisms do not yet meet some
stakeholders' expectations. As the US government (through the National
Telecommunications and Information Administration (NTIA)) has stressed that it
expects community consensus on the transition, this gap between the current
situation and stakeholder expectations needed to be addressed. This resulted in
the creation of a Cross Community Working Group
on Enhancing ICANN Accountability (CCWG-Accountability) of which the GNSO is a
chartering organization.
In May 2015, the
CCWG-Accountability published an initial proposal regarding its work on Work
Stream 1 for public comment. Following significant changes made as a result of
feedback received, the CCWG-Accountability published its Second
Draft Proposal for public comment in August 2015. With the assistance of further
community input, including from the ICANN Board, and discussions at several
sessions during ICANN54, the CCWG-Accountability made further adjustments to its
draft recommendations, resulting in its Third Draft Proposal that was published for public
comment on 30 November 2015.
Concurrently, the IANA
Stewardship Transition Coordination Group (ICG) – the community group formed to
consolidate the various proposals relating to the IANA stewardship transition
submitted by the Internet communities affected by the issue – announced after
ICANN54 that it had completed its task. However, before the ICG can send its
consolidated proposal to the NTIA via the ICANN Board, it needs confirmation
from the Cross Community Working Group to Develop an IANA Stewardship Transition
Proposal on Naming Related Functions (CWG-Stewardship)
that its accountability requirements have been met by the Work Stream 1
recommendations from the CCWG-Accountability. In this regard, the
CWG-Stewardship had submitted a public comment to the CCWG-Accountability which,
while noting that several of the CCWG-Accountability's latest recommendations
adequately satisfied the CWG-Stewardship's requirements, nevertheless
highlighted a number of points that in its view merited further
attention.
Following a Special
Meeting on 14 January 2016, the GNSO Council had approved a letter setting out its response to the
recommendations in the Third Draft Proposal. This was sent to the
CCWG-Accountability on 22 January.
In response to the
community input to its Third Draft Proposal, the CCWG-Accountability reworked
some of its draft recommendations, resulting in a Final Supplemental Proposal
that was sent to all its Chartering Organizations on 23 February (see https://www.icann.org/news/blog/ccwg-accountability-delivers-report-to-chartering-organization).The
Supplemental Final Proposal on Work Stream 1
Recommendations has the consensus support of the CCWG-Accountability,
and contains five minority statements (see revised Appendix A, circulated to all
Chartering Organizations on 25 February).
On 29 February, the
GNSO Council held a Special Meeting that included all the GNSO representatives
to the CCWG-Accountability. The purpose of the meeting was to receive initial
feedback from all the GNSO’s Stakeholder Groups and Constituencies, and to
identify any remaining issues of concern that may require further discussion
amongst the GNSO community. For its discussions on whether and how to adopt the
Supplemental Final Proposal, the GNSO Council followed a specific agreed
approach [INSERT
LINK]. Here the Council will review the final comments from of all its
SG/Cs, and, taking into account further discussions occurring during ICANN55,
vote on whether or not to adopt the recommendations from the CCWG-Accountability
as set forth in the Supplemental Final Proposal.
6.1 – Update (Thomas
Rickert, GNSO co-chair of the CCWG-Accountability)
6.2 – Presentation of
the motion (James
Bladel)
6.3 –
Discussion
6.4 – Council vote
(voting threshold: simple majority)
Item 7: DISCUSSION –
RDAP Implementation (15 minutes)
Building on previous
advisories, ICANN’s Security and Stability Advisory Committee (SSAC) had
recommended the replacement of the longstanding WHOIS protocol in SAC051 (see https://www.icann.org/en/groups/ssac/documents/sac-051-en.pdf).
In October 2011, the ICANN Board directed staff to produce, in
consultation with the community, a roadmap for the coordination of the technical
and policy discussions necessary to implement the recommendations outlined in
SAC 051. The Roadmap was published in 2012 (see https://www.icann.org/en/groups/ssac/documents/sac-051-roadmap-04jun12-en.pdf).
Also in 2012, the Internet Engineering Task Force (IETF) chartered the WEIRDS
(Web Extensible Internet Registration Data Services) working group, which
concluded its work in early 2015 with the publication of several specifications
defining the behavior of the Registry Data Access Protocol (RDAP), a
standardized replacement for WHOIS. ICANN-accredited registrars subject to the
2013 Registrar Accreditation Agreement (RAA), registry operators from the 2012
New gTLD round and several other gTLD registries are contractually obligated to
deploy RDAP.
In February 2014 the
ICANN Board adopted the GNSO Council’s recommendations for a new Consensus
Policy that would require the provision of “thick” WHOIS services for all gTLD
registries. The GNSO Implementation Review Team that was formed for the Thick
Whois Policy Implementation agreed with the proposal of ICANN staff to
synchronize implementation of the policy with the adoption of RDAP. On 3
December 2015 ICANN staff published a draft RDAP Operational Profile for public
comment (see https://www.icann.org/public-comments/rdap-profile-2015-12-03-en).
Public comments will be received through 15 February 2015.
Some concern has been
expressed as to the policy implications of adopting RDAP in view of a number of
other parallel efforts with potential cross-cutting impact, such as the recent
initiation by the GNSO Council of a PDP for a Next-Generation Registration
Directory Service to Replace WHOIS (see http://gnso.icann.org/en/council/resolutions#201511).
Following an expected discussion with ICANN’s Global Domains Division staff
overseeing the RDAP implementation during the GNSO Weekend Sessions at ICANN55
on the policy bases for RDAP, the linkage to Thick WHOIS, and the RDAP
Operational Profile requirements, the Council will now consider next steps and
any further actions that may be advisable at this time.
7.1 – Update (James
Bladel)
7.2 –
Discussion
7.3 – Next
steps
Item
8: Open Microphone (10
minutes)
Item 9: Any
Other Business (5 Minutes)
_________________________________
Appendix 1: GNSO
Council Voting Thresholds (ICANN Bylaws, Article X, Section 3)
9. Except as otherwise
specified in these Bylaws, Annex A hereto, or the GNSO Operating Procedures, the
default threshold to pass a GNSO Council motion or other voting action requires
a simple majority vote of each House. The voting thresholds described below
shall apply to the following GNSO actions:
a. Create an Issues
Report: requires an affirmative vote of more than one-fourth (1/4) vote of each
House or majority of one House.
b. Initiate a Policy
Development Process ("PDP") Within Scope (as described in Annex A): requires
an affirmative vote of more than one-third (1/3) of each House or more than
two-thirds (2/3) of one House.
c. Initiate a PDP Not
Within Scope: requires an affirmative vote of GNSO Supermajority.
d. Approve a PDP Team
Charter for a PDP Within Scope: requires an affirmative vote of more than
one-third (1/3) of each House or more than two-thirds (2/3) of one
House.
e. Approve a PDP Team
Charter for a PDP Not Within Scope: requires an affirmative vote of a GNSO
Supermajority.
f. Changes to an
Approved PDP Team Charter: For any PDP Team Charter approved under d. or e.
above, the GNSO Council may approve an amendment to the Charter through a simple
majority vote of each House.
g. Terminate a PDP:
Once initiated, and prior to the publication of a Final Report, the GNSO Council
may terminate a PDP only for significant cause, upon a motion that passes with a
GNSO Supermajority Vote in favor of termination.
h. Approve a PDP
Recommendation Without a GNSO Supermajority: requires an affirmative vote of a
majority of each House and further requires that one GNSO Council member
representative of at least 3 of the 4 Stakeholder Groups supports the
Recommendation.
i. Approve a PDP
Recommendation With a GNSO Supermajority: requires an affirmative vote of a GNSO
Supermajority,
j. Approve a PDP
Recommendation Imposing New Obligations on Certain Contracting Parties: where an
ICANN contract provision specifies that "a two-thirds vote of the council"
demonstrates the presence of a consensus, the GNSO Supermajority vote threshold
will have to be met or exceeded.
k. Modification of
Approved PDP Recommendation: Prior to Final Approval by the ICANN Board, an
Approved PDP Recommendation may be modified or amended by the GNSO Council with
a GNSO Supermajority vote.
l. A "GNSO
Supermajority" shall mean: (a) two-thirds (2/3) of the Council members of each
House, or (b) three-fourths (3/4) of one House and a majority of the other
House."
Appendix 2: Absentee
Voting Procedures (GNSO Operating
Procedures 4.4)
4.4.1
Applicability
Absentee voting is permitted for the following limited number
of Council motions or measures.
a. Initiate a Policy Development Process
(PDP);
b. Approve a PDP recommendation;
c. Recommend amendments to the
GNSO Operating Procedures (GOP) or ICANN Bylaws;
d. Fill a Council position
open for election.
4.4.2 Absentee ballots,
when permitted, must be submitted within the announced time limit, which shall
be 72 hours from the meeting's adjournment. In exceptional circumstances,
announced at the time of the vote, the Chair may reduce this time to 24 hours or
extend the time to 7 calendar days, provided such amendment is verbally
confirmed by all Vice-Chairs present.
4.4.3 The GNSO
Secretariat will administer, record, and tabulate absentee votes according to
these procedures and will provide reasonable means for transmitting and
authenticating absentee ballots, which could include voting by telephone, e-
mail, web-based interface, or other technologies as may become
available.
4.4.4 Absentee balloting does not affect quorum requirements.
(There must be a quorum for the meeting in which the vote is
initiated.)
Reference (Coordinated
Universal Time) UTC 13:30
Local time between October and March Winter in the
NORTHERN
hemisphere
----------------------------------------------------------------------------
California, USA
(PDT) UTC-7+1DST
05:30
San José, Costa Rica UTC-6+0DST 07:30
Iowa City, USA
(CDT) UTC-6+0DST
07:30
New York/Washington DC, USA (EST) UTC-5+0DST 08:30
Buenos Aires,
Argentina (ART) UTC-3+0DST
10:30
Rio de Janiero, Brazil (BRST) UTC-2+0DST 10:30
London, United
Kingdom (BST) UTC+0DST 13:30
Bonn, Germany (CET) UTC+1+0DST 14:30
Cairo,
Egypt, (EET) UTC+2+0DST 15:30
Istanbul, Turkey (EEST) UTC+3+0DST 15:30
Perth, Australia (WST) UTC+8+1DST
21:30
Singapore (SGT) UTC +8 21:30
Sydney/Hobart, Australia (AEDT)
UTC+11+0DST 00:30 next
day
----------------------------------------------------------------------------
DST
starts/ends on last Sunday of October 2016, 2:00 or 3:00 local time (with
exceptions)
----------------------------------------------------------------------
For
other places see http://www.timeanddate.com
http://tinyurl.com/jzasfwr
Kind
regards,
Glen
de Saint Géry