<<<
Chronological Index
>>> <<<
Thread Index
>>>
[council] Updated Council motions for 22 June 2011 at 14:00
- To: Council GNSO <council@xxxxxxxxxxxxxx>
- Subject: [council] Updated Council motions for 22 June 2011 at 14:00
- From: Glen de Saint Géry <Glen@xxxxxxxxx>
- Date: Tue, 21 Jun 2011 01:15:31 -0700
- Accept-language: fr-FR, en-US
- Acceptlanguage: fr-FR, en-US
- List-id: council@xxxxxxxxxxxxxx
- Sender: owner-council@xxxxxxxxxxxxxx
- Thread-index: Acwv62M76qcSsG4RSsKxTjVI1/98UQ==
- Thread-topic: Updated Council motions for 22 June 2011 at 14:00
Dear All,
Please find the updated motions for the Council meeting tomorrow:
https://community.icann.org/display/gnsocouncilmeetings/Motions+22+June+2011
Motion 1 on the Adoption of the IRTP Part B Final Report and Recommendations
Made by: Tim Ruiz
Seconded by: Jonathan Robinson
Motion on the Adoption of the IRTP Part B Final Report and Recommendations
WHEREAS on 24 June 2009, the GNSO Council launched a Policy Development Process
(PDP) on IRTP Part B addressing the following five charter questions:
a. Whether a process for urgent return/resolution of a domain name should be
developed, as discussed within the SSAC hijacking report
(http://www.icann.org/announcements/hijacking-report-12jul05.pdf); see also
(http://www.icann.org/correspondence/cole-to-tonkin-14mar05.htm);
b. Whether additional provisions on undoing inappropriate transfers are needed,
especially with regard to disputes between a Registrant and Admin Contact (AC).
The policy is clear that the Registrant can overrule the AC, but how this is
implemented is currently at the discretion of the registrar;
c. Whether special provisions are needed for a change of registrant when it
occurs near the time of a change of registrar. The policy does not currently
deal with change of registrant, which often figures in hijacking cases;
d. Whether standards or best practices should be implemented regarding use of a
Registrar Lock status (e.g. when it may/may not, should/should not be applied);
e. Whether, and if so, how best to clarify denial reason #7: A domain name was
already in 'lock status' provided that the Registrar provides a readily
accessible and reasonable means for the Registered Name Holder to remove the
lock status.
WHEREAS this PDP has followed the prescribed PDP steps as stated in the Bylaws,
resulting in a Final Report delivered on 30 May 2011;
WHEREAS the IRTP Part B WG has reached full consensus on the recommendations in
relation to each of the five issues outlined above;
WHEREAS the GNSO Council has reviewed and discussed these recommendations.
Resolved
Required Voting Threshold [1]
RESOLVED (A), the GNSO Council recommends to the ICANN Board of Directors:
1. Requiring Registrars to provide a Transfer Emergency Action Contact (TEAC).
To this end the language of section 4 (Registrar Coordination) and Section 6
(Registry Requirements of the Inter-Registrar Transfer Policy should be updated
as follows:
Transfer Emergency Action Contact (Append to Section 4)
Registrars will establish a Transfer Emergency Action Contact (TEAC) for urgent
communications relating to transfers. The goal of the TEAC is to quickly
establish a real-time conversation between registrars (in a language that both
parties can understand) in an emergency. Further actions can then be taken
towards a resolution, including initiating existing (or future) transfer
dispute or undo processes.
Communications to TEACs will be reserved for use by ICANN-Accredited
Registrars, gTLD Registry Operators and ICANN Staff. The TEAC point of contact
may be designated as a telephone number or some other real-time communication
channel and will be recorded in, and protected by, the ICANN RADAR system.
Communications to a TEAC must be initiated in a timely manner, within a
reasonable period of time following the alleged unauthorized loss of a domain.
Messages sent via the TEAC communication channel must generate a non-automated
response by a human representative of the gaining Registrar. The person or team
responding must be capable and authorized to investigate and address urgent
transfer issues. Responses are required within 4 hours of the initial request,
although final resolution of the incident may take longer.
The losing registrar will report failures to respond to a TEAC communication to
ICANN Compliance and the registry operator. Failure to respond to a TEAC
communication may result in a transfer-undo in accordance with Section 6 of
this policy and may also result in further action by ICANN, up to and including
non-renewal or termination of accreditation.
Both parties will retain correspondence in written or electronic form of any
TEAC communication and responses, and share copies of this documentation with
ICANN and the registry operator upon request. This documentation will be
retained in accordance with Section 3.4 of the Registrar Accreditation
Agreement (RAA). Users of the TEAC communication channel should report
non-responsive Registrars to ICANN. Additionally, ICANN may conduct periodic
tests of the Registrar TEAC communication channel in situations and a manner
deemed appropriate to ensure that registrars are indeed responding to TEAC
messages.
(Append to Section 6) 6 iv. Documentation provided by the Registrar of Record
prior to transfer that the Gaining Registrar has not responded to a message via
the TEAC within the timeframe specified in Section 4.
In addition, update section 6 to reflect that the registry, in case of a
transfer undo, will reverse the transfer and reset the registrar of record
filed to its original state ('In such case, the transfer will be reversed and
the Registrar of Record field reset to its original state'). (IRTP Part B
Recommendation #1)
2. Modifying section 3 of the IRTP to require that the Registrar of
Record/Losing Registrar be required to notify the Registered Name
Holder/Registrant of the transfer out. The Registrar of Record has access to
the contact information for the Registrant and could modify their systems to
automatically send out the Standardized Form for Losing Registrars
("Confirmation FOA") to the Registrant. (IRTP Part B Recommendation #5)
3. Modifying Reason for Denial #6 as follows: Express objection to the transfer
by the authorized Transfer Contact. Objection could take the form of specific
request (either by paper or electronic means) by the authorized Transfer
Contact to deny a particular transfer request, or a general objection to all
transfer requests received by the Registrar, either temporarily or
indefinitely. In all cases, the objection must be provided with the express and
informed consent of the authorized Transfer Contact on an opt-in basis and upon
request by the authorized Transfer Contact, the Registrar must remove the lock
or provide a reasonably accessible method for the authorized Transfer Contact
to remove the lock within five (5) calendar days. (IRTP Part B Recommendation
#6)
4. Deleting denial reason #7 as a valid reason for denial under section 3 of
the IRTP as it is technically not possible to initiate a transfer for a domain
name that is locked, and hence cannot be denied, making this denial reason
obsolete. (IRTP Part B Recommendation #9 - part 1)
More than 75% of one House and a majority of the other House ("GNSO
Supermajority")
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 with respect to any contracting
party affected by such contract provision. In the event a GNSO Supermajority
Vote is not achieved, approval of the recommendations contained in the Final
Report requires a majority of both houses and further requires that one
representative of at least 3 of the 4 Stakeholder Groups supports the
recommendations. Abstentions shall not be permitted; thus all Council members
must cast a vote unless they identify a financial interest in the outcome of
the policy issue.[2]
RESOLVED (B), the GNSO Council recommends the promotion by ALAC and other ICANN
structures of the measures outlined in the recent report of the Security and
Stability Advisory Committee on A Registrant's Guide to Protecting Domain Name
Registration Accounts (SAC 044). In particular, the GNSO Council recommends
that registrants consider the measures to protect domain registrar accounts
against compromise and misuse described in SAC044, Section 5. These include
practical measures that registrants can implement "in house", such as ways to
protect account credentials and how to incorporate domain name registrations
into employee or resource management programs typically found in medium and
large businesses. It suggests ways that registrants can use renewal and change
notifications from registrars as part of an early warning or alerting system
for possible account compromise. The GNSO Council Chair will reach out to the
ALAC and other ICANN structures to inform them of this recommendation and
discuss how the GNSO may contribute to this promotion. (IRTP Part B
Recommendation #2)
Approve a PDP Recommendation With a GNSO Supermajority: requires an affirmative
vote of a GNSO Supermajority
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
RESOLVED (C), the GNSO Council recommends that if a review of the UDRP is
conducted in the near future, the issue of requiring the locking of a domain
name subject to UDRP proceedings is taken into consideration. (IRTP Part B
Recommendation #7)
Approve a PDP Recommendation With a GNSO Supermajority: requires an affirmative
vote of a GNSO Supermajority
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
RESOLVED (D), prior to the consideration of approval of the recommendation
which states: "denial reason #7 should be replaced by adding a new provision in
a different section of the IRTP on when and how domains may be locked or
unlocked", the GNSO Council requests ICANN Staff to provide a proposal for such
a new provision, taking into account the IRTP Part B WG deliberations in
relation to this issue (see IRTP Part B Final Report - (Recommendation #9 -
part 2). Upon review of the proposal, the GNSO Council will consider whether to
approve the recommendation.
Simple majority vote of each House
RESOLVED (E), prior to the consideration of approval of the recommendation
regarding the standardizing and clarifying WHOIS status messages regarding
Registrar Lock status, the GNSO Council requests ICANN staff to provide a
proposal designed to ensure a technically feasible approach can be developed to
meet this recommendation. Staff should take into account the IRTP Part B WG
deliberations in relation to this issue (see IRTP Part B Final Report). (IRTP
Part B Recommendation #8). The goal of these changes is to clarify why the Lock
has been applied and how it can be changed. Upon review of the proposed plan,
the GNSO Council will consider whether to approve the recommendation.
Simple majority vote of each House
RESOLVED (F), the GNSO Council requests an Issues Report on the requirement of
'thick' WHOIS for all incumbent gTLDs. Such an Issue Report and possible
subsequent Policy Development Process should not only consider a possible
requirement of 'thick' WHOIS for all incumbent gTLDs in the context of IRTP,
but should also consider any other positive and/or negative effects that are
likely to occur outside of IRTP that would need to be taken into account when
deciding whether a requirement of 'thick' WHOIS for all incumbent gTLDs would
be desirable or not. (IRTP Part B Recommendation #3)
At least twenty-five percent (25%) of the members of the Council of each House
or a majority of one House.
RESOLVED (G), the GNSO Council requests an Issue Report on IRTP Part C, which
should include:
- "Change of Control" function, including an investigation of how this function
is currently achieved, if there are any applicable models in the country-code
name space that can be used as a best practice for the gTLD space, and any
associated security concerns. It should also include a review of locking
procedures, as described in Reasons for Denial #8 and #9, with an aim to
balance legitimate transfer activity and security. (IRTP Part B Recommendation
#4)
- Whether provisions on time-limiting FOAs should be implemented to avoid
fraudulent transfers out. For example, if a Gaining Registrar sends and
receives an FOA back from a transfer contact, but the name is locked, the
registrar may hold the FOA pending adjustment to the domain name status, during
which time the registrant or other registration information may have changed.
- Whether the process could be streamlined by a requirement that registries use
IANA IDs for registrars rather than proprietary IDs.
At least twenty-five percent (25%) of the members of the Council of each House
or a majority of one House.
MOTION 2. RE. REVISION OF THE GNSO COUNCIL OPERATING PROCEDURES RELATING TO
PROXY VOTING
Made by: Wolf-Ulrich Knoben
Seconded by: Stéphane van Gelder
WHEREAS, the GNSO Council recently identified areas for improvement in the GNSO
Council Operating Procedures that would simplify and clarify the procedures
relating to proxy voting;
WHEREAS, the GNSO Council tasked the Operations Steering Committee (OSC) with
completing a revision to improve the procedures relating to proxy voting;
WHEREAS, the OSC submitted to the GNSO Council on 14 June 2011 recommended
revisions
http://gnso.icann.org/drafts/osc-recommended-revisions-proxy-voting-14jun11-en.pdf
to the GNSO Council Operating Procedures to simplify and clarify the
procedures relating to proxy voting;
NOW THEREFORE, BE IT:
RESOLVED, that the GNSO Council acknowledges receipt of the recommended
revisions submitted by the OSC and directs Staff produce a redlined revision of
the GNSO Council Operating Procedures incorporating the recommended revisions
and to post this document for twenty-one (21) days in the ICANN Public Comment
Forum.
RESOLVED FURTHER, that the GNSO Council shall take formal action on these
recommendations, including potential modification, as soon as possible after
the conclusion of the public comment period.
Glen de Saint Géry
GNSO Secretariat
gnso.secretariat@xxxxxxxxxxxxxx
http://gnso.icann.org
________________________________
[1] As a reminder, the level of support received from the GNSO Council for the
recommendation (GNSO Supermajority or no GNSO Supermajority) determines the
voting threshold required by the Board to reject a GNSO Council recommendation
as outlined in section 13 Board Vote of Annex A of the ICANN Bylaws.
[2] In the event that this recommendation is not approved by a GNSO
supermajority vote, the recommendations would not be considered consensus
policy and therefore not be binding on existing contracted parties.
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|