RE: [council] IRTP Part B Motions for action in Sydney

["Gomes, Chuck" <cgomes@xxxxxxxxxxxx>]

I will second both of these motions.

Chuck 

> -----Original Message-----
> From: owner-council@xxxxxxxxxxxxxx 
> [mailto:owner-council@xxxxxxxxxxxxxx] On Behalf Of Tim Ruiz
> Sent: Wednesday, June 10, 2009 8:44 AM
> To: GNSO Council 
> Subject: [council] IRTP Part B Motions for action in Sydney
> 
> I am making the following two motions regarding IRTP Part B 
> (drafted in consultation with the Transfers WG) for 
> consideration in Sydney. Seconds please. The motions are also 
> attached as a doc file.
> 
> Tim
> 
> Motion I - Initiation of a PDP on IRTP Part B
> 
> Whereas
> The Inter-Registrar Transfer Policy (IRTP) is an existing 
> consensus policy under review by the GNSO,
> 
> The GNSO Transfers Working Group identified a number of 
> issues in its review of the current Policy and those issues 
> have been grouped into suggested PDPs, set A-E, as per the 
> Council's resolution of 8 May 2008,
> 
> The GNSO Council, in order to be more efficient and hopefully 
> reduce the overall timeline for addressing all the IRTP PDPs, 
> resolved on 16 April
> 2009 to combine the issues outlined under the original issue 
> set B, addressing three issues on undoing IRTP transfers, and 
> some of the issues outlined in issue set C, related to 
> registrar lock status into one IRTP Part B,
> 
> The GNSO Issues Report Inter-Registrar Transfer Policy Part B 
> was submitted to the GNSO Council on 15 May 2009,
> 
> The Issues Report recommends that the GNSO Council proceed 
> with a Policy Development Process limited to consideration of 
> the issues discussed in this report, and
> 
> The General Counsel of ICANN has indicated the topic is 
> properly within the scope of the ICANN policy process and 
> within the scope of the GNSO
> 
> Resolved
> The GNSO will initiate a PDP on the issues defined in Inter 
> Registrar Transfer Policy Issues Report Part B.
> 
> A Working Group will be created for the purpose of fulfilling 
> the requirements of the PDP.
> 
> Motion II - Approval of a Charter for the IRTP Part B WG
> 
> Whereas
> On [date] 2009 the GNSO Council initiated PDP IRTP Part B 
> and, decided to create a PDP WG for the purposes of 
> fulfilling the requirements of the PDP, and,
> 
> The GNSO Council has reviewed the charter.
> 
> Resolved
> The GSNO Council approves the charter and appoints Tim Ruiz 
> confirmed as the GNSO Council Liaison to the IRTP PDP Part B WG. 
> 
> The GNSO council further directs that the work of the IRTP 
> Part B WG be initiated no later then 14 days after the 
> approval of this motion. Until such time as the WG can select 
> a chair and that chair can be confirmed by the GNSO Council, 
> the GNSO council Liaison shall act as interim chair.
> 
> Charter
> The Working Group shall consider the following questions as 
> outlined in the issues report and make recommendations to the 
> GNSO Council: 
> 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.p
> df); 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.
> 
> Working Group processes:
> While the development of Guidelines for Working Group 
> operations are still to be developed the following guidelines 
> will apply to this WG:
> - The WG shall function on the basis of rough consensus, 
> meaning all points of view will be discussed until the chair 
> can ascertain that the point of view is understood and has 
> been covered. Consensus views should include the names and 
> affiliations of those in agreement with that view.
> Anyone with a minority view will be invited to include a 
> discussion in the WG report. Minority report should include 
> the names and affiliations of those contributing to the 
> minority report.
> 
> - In producing the WG report, the chair will be responsible 
> for designating each position as having one of the following 
> designations:
> --- Unanimous consensus position
> --- Rough consensus position - a position where a small 
> minority disagrees but most agree
> --- Strong support but significant opposition
> --- Minority viewpoint(s)
> 
> - If several participants in a WG disagree with the 
> designation given to a position by the chair or any other 
> rough consensus call, they can follow these steps sequentially:
>   1. Send email to the chair, copying the WG explaining why 
> the decision is believed to be in error.
>   2. If the chair still disagrees, forward the appeal to the council
> liaison(s) to the group. The chair must explain his or her 
> reasoning in the response. * If the liaisons support the 
> chair's position, forward the appeal to the council. The 
> liaison(s) must explain his or her reasoning in the response.
>   3. If the council supports the chair and liaison's 
> position, attach a statement of the appeal to the board 
> report. This statement should include all of the 
> documentation from all steps in the appeals process and 
> should include a statement from the council.
> 
> - The chair, in consultation with the GNSO council liaison(s) 
> is empowered to restrict the participation of someone who 
> seriously disrupts the WG. Any such restriction will be 
> reviewed by the GNSO council. Generally the participant 
> should first be warned privately, and then warned publicly 
> before such a restriction is put into place. In extreme 
> circumstances this requirement may be bypassed.
> 
> - The WG will have an archived mailing list. The mailing list 
> will be open for reading by the community. All WG meetings 
> will be recorded and all recordings will be available to the 
> public. A IRTP PDP B mailing list has been created 
> (Gnso-irtp-b-jun09@xxxxxxxxx) and the public archives are at 
> http://gnso.icann.org/mailing-lists/. 
> 
> - A SocialText wiki has been provided for WG usage and can be 
> found at https://st.icann.org/irtp-partb/index.cgi?irtp_part_b 
> 
> - If the guidelines for WG processes change during the course 
> of the WG, the WG may continue to work under the guidelines 
> active at the time it was (re)chartered or use the new guidelines.
> 
> - The council liaisons to the WG will be asked to report on 
> the WG status monthly to the council.
> 
> - All WG charters must be reviewed by the GNSO council every 
> 6 months for renewal.
> 
> Milestones 
> - WG formed, chair & Council liaison & staff coordinator 
> identified    = T
> - Initial Report: T + 170 days
> - First comment period ends: T + 190 days
> - Preliminary Final Report: T + 220 days.
> 
> Note: If the WG decides that a change is needed to the 
> milestone dates, it should submit a revised time line to the 
> GNSO council for approval
> 
>