Item Inter-Registrar Transfer Policy (IRTP) Part A Policy Development Process (PDP)
Proposed Motion on the Inter-Registrar Transfer Policy (IRTP) Part A Policy Development Process (PDP)
Motion by: Mike Rodenbaugh
Seconded by: Chuck Gomes
Whereas:
On 25 June 2008, the GNSO Council launched a Policy Development Process (PDP) on three "new" issues identified by the Transfers Working Group in 2008 addressing
(1) the potential exchange of registrant email information between registrars,
(2) the potential for including new forms of electronic authentication to verify transfer requests and avoid "spoofing," and
(3) to consider whether the IRTP should include provisions for "partial bulk transfers" between registrars;
Whereas this PDP has followed the prescribed PDP steps as stated in the Bylaws, resulting in a Final Report delivered on 19 March 2009;
Whereas the IRTP Part A WG has reached consensus on the recommendations in relation to each of the three issues outlined above;
Whereas these recommendations do not include any proposals for changes to the Inter-Registrar Transfer Policy, but do recommend that the GNSO Council:
(1) Carry out an assessment of whether IRIS would be a viable option for the exchange of registrant email address data between registrars and conduct an analysis of IRIS' costs, time of implementation and appropriateness for IRTP purposes;
(2) Suggest that future IRTP working groups consider the appropriateness of a policy change that would prevent a registrant from reversing a transfer after it has been completed and authorized by the admin contact; and,
(3) Clarify that the current bulk transfer provisions also apply to a bulk transfer of domain names in only one gTLD.
Whereas the GNSO Council has reviewed and discussed these recommendations;
The GNSO Council RESOLVES:
To encourage staff to explore further assessment of whether IRIS would be a viable option for the exchange of registrant email address data between registrars and conduct an analysis of IRIS' costs, time of implementation and appropriateness for IRTP purposes.
To include in future IRTP working groups the issue of the appropriateness of a policy change that would prevent a registrant from reversing a transfer after it has been completed and authorized by the admin contact.
Recommends that ICANN staff communicate to registries and registrars that the current bulk transfer provisions do apply to cases requiring the transfer of all names in one single gTLD under management of a registrar.
Footnote:
From the Policy on Transfer of Registrations between Registrars: 'Transfer of the sponsorship of all the registrations sponsored by one Registrar as the result of
(i) acquisition of that Registrar or its assets by another Registrar, or
(ii) lack of accreditation of that Registrar or lack of its authorization with the Registry Operator, may be made according to the following procedure:(a) The gaining Registrar must be accredited by ICANN for the Registry TLD and must have in effect a Registry-Registrar Agreement with Registry Operator for the Registry TLD.
(b) ICANN must certify in writing to Registry Operator that the transfer would promote the community interest, such as the interest in stability that may be threatened by the actual or imminent business failure of a Registrar.
Upon satisfaction of these two conditions, the Registry Operator will make the necessary one-time changes in the Registry database for no charge, for transfers involving 50,000 name registrations or fewer. If the transfer involves registrations of more than 50,000 names, Registry Operator will charge the gaining Registrar a one-time flat fee of US$ 50,000.'
Motion on next round of IRTP issues to address
Made by Tim Ruiz
Seconded by Mike Rodenbaugh
WHEREAS,
The Inter-Registrar Transfer Policy (IRTP) is an existing consensus
policy under review by the GNSO,
A GNSO group of volunteers assigned five PDP groupings to 19 identified
IRTP issues, based on a previously developed prioritized issues list,
Three additional issues were added to IRTP C based on recommendations
from the IRTP Denial Definitions WG and the Issues Report on
Post-Expiration Domain Name Recovery,
The IRTP Part A WG has recommended combining the issues outlined under
PDP B and some of the issues outlined under PDP C into one PDP B in
order to be more efficient and hopefully reduce the overall timeline for
addressing all the IRTP PDPs,
The GNSO Council retains the option to address the issues outlined below
in one PDP or two separate PDPs following the completion of the issues
report,
RESOLVED,
Pursuant to section 1.b of Annex A of ICANN's Bylaws, that the GNSO
Council requests the creation of an issues report on the following
issues:
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).
(Issue #2)
b) Whether additional provisions on undoing inappropriate transfers are
needed, especially with regard to disputes between a Registrant and
Admin Contact. The policy is clear that the Registrant can overrule the
AC, but how this is implemented is currently at the discretion of the
registrar. (Issue #7)
c) Whether special provisions are needed for a change of registrant near
a change of registrar. The policy does not currently deal with change of
registrant, which often figures in hijacking cases. (Issue #9)
d) Whether standards or best practices should be implemented regarding
use of Registrar Lock status (e.g., when it may/may not, should/should
not be applied). (Issue #5)
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. (Recommendation from the IRTP Denials WG)
(Note: The issue numbers included above refer to the original numbering
in the Transfers Working Group list. Issues a to c form the original
PDP B, while issue d comes from the original PDP C.)
Notwithstanding section 2 of Annex A of the Bylaws, and in
recognition of Staff's current workload, Council requests that Staff
complete the issues report and delivers it to the Council by 16 May or
reports on its progress by that date with a target date for completion.
----------------------------------------------------------------------------------------------------------------------------
Item : Post-Expiration Domain Name Recovery Policy Development Process (PDP) decision (Alan Greenberg/Drafting Team)
Proposed Motion on Post-Expiration Domain Name Recovery
Motion by: Avri Doria
Seconded by:
Whereas on 05 December 2008, the GNSO received an Issues Report on Post-Expiration Domain Name Recovery (PEDNR);
Whereas on 29 January 2009 the GNSO Council decided to form a Drafting Team (DT) to consider the form of policy development action in regard to PEDNR;
Whereas a DT has formed and its members have discussed and reviewed the issues documented in the Issues Report;
Whereas the DT has concluded that although some further information gathering may be needed, it should be done under the auspices of a PDP;
Whereas staff has suggested and the DT concurs that the issue of registrar transfer during the RGP might be better handled during the IRTP Part C PDP.
The GNSO Council RESOLVES
to initiate a Policy Development Process (PDP) to address the issues identified in the Post-Expiration Domain Name Recovery Issues Report. The charter of the Task Force or Working Group charged with carrying out this PDP should include a mandate to consider both Consensus Policy recommendations as well as recommendations regarding best practices, ICANN compliance obligations and possible RAA changes, all associated with staff recommendations in the Issues Report section 4.2.
Specifically, consideration of the following questions:
. Whether adequate opportunity exists for registrants to redeem their expired domain names;
. Whether expiration-related provisions in typical registration agreements are clear and conspicuous enough;
. Whether adequate notice exists to alert registrants of upcoming expirations;
. Whether additional measures need to be implemented to indicate that once a domain name enters the Auto-Renew Grace Period, it has expired (e.g., hold status, a notice on the site with a link to information on how to renew, or other options to be determined).
. Whether to allow the transfer of a domain name during the RGP.
The GNSO Council further resolves that the issue of logistics of possible registrar transfer during the RGP shall be incorporated into the charter of the IRTP Part C charter.
Motion on Producing Synthesis of Requirements for Whois Service Tools
Made by: Avri Doria
Seconded by: Chuck Gomes
Whereas there have been discussions for several years on the adequacy of the current set of Whois tools to provide the necessary functions to support existing and proposed Whois service policy requirements,
and, there have been questions as to the adequacy of these tools for use in an IDN environment,
and, that there have been extensive discussions about the requirements of the Whois service with respect to Registry and registrar operations,
and, new architectures and tools have been developed and suggested by the technical community,
Resolved,
The GNSO Council requests that Policy Staff, with the assistance of technical staff as required, collect and organize a comprehensive set of requirements for the Whois service policy tools. These requirements should reflect not only the known deficiencies in the current service but should include any possible requirements that may be needed to support various policy initiatives such as tiered services and privacy protection.
The synthesis of requirements should be done in consultation with the SSAC, ALAC, GAC and the ccNSO and (a strawman proposal should be prepared for these consultation. The Staff is asked to come back with an estimate of when this would be possible.) should be ready for community discussion in time for the Sydney meeting.
Motion on Travel Funding
Ammendment
Motion: Cyril Chua
Second:
That the resolution be changed to read:
That, without prejudice to each constituency's existing credits, the DNSO funds be distributed evenly across all six GNSO Constituencies in time for the Sydney meeting in June, with the express purpose of providing additional Travel Funding for those persons nominated by each Constituency as recipients to be of said Travel Support.
Made by Stéphane van Gelder
Seconded by Philip Sheppard
Whereas:
At its meeting of September 25, 2008 the GNSO Council created the Travel
Drafting Team (TDT) to work on proposals to optimize the allocation and the
management of Travel Funding for the GNSO Constituencies.
At a meeting held during the Mexico ICANN meeting in March 2009 between the
TDT and members of ICANN staff, the TDT requested that all GNSO
Constituencies receive Funding Slots for each of their elected Councillors
at each one of the three yearly international ICANN meetings, with the
understanding that it would then be up to each Constituency to allocate
these slots according to their own internal processes.
That request stemmed in part from the recognition of the significant, and
ever increasing work loads, that GNSO Councillors face. Work which they
carry out as unpaid volunteers.
Since that meeting it has been identified that an amount of funds left over
from the DNSO are available for use should the Council wish to provide
additional Travel Funding to those GNSO Constituencies that no longer have
enough credits left for their three slots for the final meeting of the
fiscal year 2008, in Sydney.
The funds identified are in the amount of 19,963.79 USD.
Resolved:
That the DNSO funds be distributed evenly across all six GNSO Constituencies
in time for the Sydney meeting in June, with the express purpose of
providing additional Travel Funding for those persons nominated by each
Constituency as recipients to be of said Travel Support.