May 2008 - council - lists.icann.org

had to drop off
by Thomas Keller May 29, 2008

May 29, 2008

Hello, I had to drop off our call due to another meeting. Sorry, tom -- Thomas Keller Business Development 1&1 Internet AG Brauerstrasse 48 Tel. +49-721-91374-4534 76135 Karlsruhe, Germany Fax +49-721-91374-2739 1und1.de Mail tom(a)1und1.de Amtsgericht Montabaur HRB 6484 Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, Andreas Gauger, Thomas Gottschlich, Matthias Greve, Robert Hoffmann, Markus Huhn, Achim Weiss Aufsichtsratsvorsitzender: Michael Scheeren

1 0

WHOIS study group report attached
by Liz Gasster May 29, 2008

May 29, 2008

Council members: Attached please find the final report of the WHOIS study group, which was convened by the Council on 27 March to examine the study recommendations suggested by the public (and later augmented with study suggestions recommended by the Government Advisory Committee), and to make a recommendation to the Council. Also, in the course of discussions on further studies of WHOIS, study participants asked for more information on IRIS and specifically more information about what it would take to implement IRIS from both a technical and policy perspective. Steve Crocker has provided an email response (also attached), and has also offered to participate in a Q & A or broader discussion, at which SSAC experts could have a dialogue with the GNSO Council and constituency representatives. Staff would be happy to coordinate such a conversation at the Council's request. The WHOIS study group would be glad to answer questions about the report and our deliberation process. Thanks, Liz Gasster Study group participants: Jordi Iparraguirre Ken Stubbs David Maher Steve Metalitz Lee Eulgen Steve DelBianco Tony Harris Tim Ruiz Paul Stahura James Bladel Stéphane Van Gelder Norbert Klein Robin Gross Danny Younger Beau Brendler Wendy Seltzer Liz Gasster - staff

2 3

Fast Flux Charter
by Gomes, Chuck May 29, 2008

May 29, 2008

I would like to suggest the following changes to the Fast Flux charter. Regarding the questions that are part of the Charter: From: How are registry operators involved in fast flux hosting activities? To: Are registry operators involved in fast flux hosting activities? If so, how? From: How are registrars involved in fast flux hosting activities? To: Are registrars involved in fast flux hosting activities? If so, how? After: What would be the impact (positive or negative) of establishing limitations, guidelines, or restrictions on registrants, registrars and/or registries with respect to practices that enable or facilitate fast flux hosting? Add: What would be the impact of these limitations, guidelines, or restrictions to product and service innovation at the edge? Chuck Gomes

3 2

Additional information on single-character names
by Patrick Jones May 29, 2008

May 29, 2008

Dear Council members, Because of the overlap between the Council call and the Board call, this email is intended to provide additional information from ICANN staff in advance of the discussion on 29 May regarding single-character names at the second-level. * Contractual provisions in ICANN's registry agreements govern how we act. In addition, new Registry Services are governed by the GNSO Policy, which was put into the contractual provisions of the registry agreements. * ICANN cannot unilaterally change the registry agreements and the Schedule of Reserved Names. There is no Policy which states that registries must release single-character names at the second-level. * A registry can be released from its obligations related to its Schedule of Reserved Names on ICANN's approval pursuant to the specific contractual provisions in the registry agreements. We are going through staff work to determine the appropriate mechanism for release - this work includes the development of a paper on allocation methods and uses of funds from allocation of single-character names, and because this affects all registries, the development of a process for release of single-letter names. * The Reserved Names Working Group (RN WG) developed policy recommendations on single-character names at the second-level for new gTLDs, and for existing gTLDs, stating that release should be "contingent upon the use of appropriate allocation frameworks. More work may be needed." * As the Council is aware, these recommendations are not consensus policy because they do not follow the consensus policy process. Therefore, the RN WG recommendations and subsequent staff work does not raise new duties or obligations for registries. * A one-size-fits-all method may not work for all registries. * Based on the direction of the Council, the public comment period and synthesis document, ICANN staff will publish a paper regarding a proposed allocation method and distribution of funds model for community consideration. I will be available on Sunday 21 June during the GNSO Working Session in Paris to answer questions on this topic. Regards, Patrick -- Patrick L. Jones Registry Liaison Manager & Coordinator, ICANN Nominating Committee Internet Corporation for Assigned Names & Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: +1 310 301 3861 Fax: +1 310 823 8649 patrick.jones(a)icann.org

1 0

Re: [council] Fwd: Charter for Fast Flux PDP WG
by Avri Doria May 29, 2008

May 29, 2008

Hi, The concept is one that i support and may have even been one of those to suggest it. It is a concept that springs from looking at other organizations that have WG structures that are managed by council like bodies. And from experience with WGs in other organizations. council, steering rups and committees seem to wrk best when there is a bit of seperation between the management of the Wg and the membership of the supervising council. Part of the idea is also that the improvements are being done to pull more people into the process and to make the GSNO council more of a management group then the prime group actually doing the work. In some sense, to me, this means that as much as possible we should be managing the process and I believe we can do that most objectively if we are not also directly managing the WGs. The idea behind the liaison from the council is for there to be someone who, in addition to the (co)chairs, can provide a link with the management structure. The guideline is not meant to be a prohibition, but a guideline. In terms of having the group self select its chair, part of my concern is to make sure that WG have chairs who know how to manage a WG to consensus and who we believe as a council have the skills to deal with a group composed of a widespread cross-section of the community. If he council is to manage the process, it might make sense to have the council pick the chairs. The WGs are a longer term constructs then the drafting teams we currently work with and will be composed of a variety of participants both from constituencies and from other parts of the community. Personally I think the council should be in the position of picking chairs and should be able to replace a WG chair who is not working out. In the long term, these are issues to be resolved as part of the GNSO "improvements" process. Since this WG is being kicked off before the creation of GNSO guidelines for Wg, these were just ideas for this particular WG. a. On 28 May 2008, at 17:00, Mike Rodenbaugh wrote: > I am not sure when the conception arose about chairs and co-chairs > not being Council members, since every group formed since I've been > on Council would violate that conception. Good concept particularly > for this PDP, but should not be deemed a rule. > In any event, why would we not allow the WG to self-select their > chair and co-chair, subject to Council approval? That also seems to > me the way things have been done to date. > > I can volunteer as Council liason since I will be participating on > this WG for the BC. > > Also, we should ensure that this WG can meet face to face in Paris, > if at all possible... since the next opportunity will not be til > Cairo and the WG ideally will be done with its work by then. > > Thanks, > Mike > > Avri Doria wrote: >> >> Hi, >> >> Again, I sent the message from the wrong email address - I sent it >> from my university account. >> >> I hope that people noticed the Fast Flux motion in the Agenda and >> have read through it for tomorrow's discussion. Please read this >> note and think about the appointments mentioned in the note. >> >> Thanks and apologies for the unintentional lateness of this notice. >> >> a. >> >> Begin forwarded message: >> >>> From: Avri Doria <avri(a)ltu.se> >>> Date: 22 May 2008 16:02:38 EDT >>> To: Council GNSO <council(a)gnso.icann.org> >>> Subject: Charter for Fast Flux PDP WG >>> >>> Hi, >>> >>> At our last meeting, we voted on a motion to create a WG for the >>> purposes of proceeding with the work on the Fast Flux PDP. A >>> proposed charter was due to the Council by today. That charter >>> can be found on the Socialtext GNSO work space under [Fast Flux] >>> (aka https://st.icann.org/gnso-council/index.cgi?fast_flux) I >>> have also included a copy of that charter below. >>> >>> Discussion and, if at all possible, a vote on this charter is >>> scheduled for our meeting of 29 May. Prior discussion on the list >>> before then is encouraged so that any edits can be made early if >>> possible. >>> >>> Additionally, in reading through the charter you will note that >>> several roles are marked TBD. >>> >>> Specifically >>> >>> - a chair or co-chairs need to be appointed. The conception we >>> have had of this group, and working groups in general, is that the >>> chair or co-chairs, should _not_ be council members. I therefore >>> look to the council members to provide suitable candidates for us >>> to discuss. >>> >>> - a council liaison who will act as the point of contact between >>> the WG and the council as described in the charter. In this case >>> the council will need to choose between whomever on the council >>> volunteers for this role. Though I do believe that council >>> members should be able to participate in WGs in their individual >>> capacities without being chosen as the liaison to the WG. >>> >>> (During the council meeting, I will ask whether the group whether >>> we want to go off recording while we discuss these staffing >>> issues. In the past we have decided to keep the call on the >>> public record even when discussing staff issues, and I am >>> personally comfortable with doing so again as long as we do so >>> deliberately.) >>> >>> I look forward to your feed back on this charter. It is the first >>> approximation at some of the processes and procedures we may adopt >>> as part of the "improvements" process and is based on our >>> successful previous experiences with WGs. >>> >>> thanks >>> >>> a. >>> >>> >>> --- >>> >>> PDP Working group on Fast Flux Issues >>> >>> hereas Council has decided to launch a PDP to consider potential >>> policy development to address fast flux hosting; >>> >>> The GNSO Council RESOLVES: >>> >>> To form a Working Group of interested stakeholders and >>> Constituency representatives, to collaborate broadly with >>> knowledgeable individuals and organizations, in order to develop >>> potential policy options to curtail the criminal use of fast flux >>> hosting. The WG is also open to invited experts and to members of >>> the ICANN advisory committees whether acting in their own right or >>> as representatives of their AC. >>> Charter >>> >>> The Working Group initially shall consider the following questions: >>> >>> * Who benefits from fast flux, and who is harmed? >>> >>> * Who would benefit from cessation of the practice and who would >>> be harmed? >>> >>> * How are registry operators involved in fast flux hosting >>> activities? >>> >>> * How are registrars involved in fast flux hosting activities? >>> >>> * How are registrants affected by fast flux hosting? >>> >>> * How are Internet users affected by fast flux hosting? >>> >>> * What technical, e.g. changes to the way in which DNS updates >>> operate, and policy, e.g. changes to registry/registrar agreements >>> or rules governing permissible registrant behavior measures could >>> be implemented by registries and registrars to mitigate the >>> negative effects of fast flux? >>> >>> * What would be the impact (positive or negative) of >>> establishing limitations, guidelines, or restrictions on >>> registrants, registrars and/or registries with respect to >>> practices that enable or facilitate fast flux hosting? >>> >>> * What are some of the best practices available with regard to >>> protection from fast flux. >>> >>> * What areas of fast flux are in scope and out of scope for GNSO >>> policy making? >>> >>> The Working Group shall report back to Council within 90 days, >>> with a report discussing these questions and the range of possible >>> answers developed by the Working Group members. The Working Group >>> report also shall outline potential next steps for Council >>> deliberation. These next steps may include further work items for >>> the WG or policy recommendation for constituency and community >>> comment and review and for council deliberation >>> Working Group processes: >>> >>> While the development of guidelines for Working 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. Anyone >>> with a minority view will be invited to include a discussion in >>> the WG report. >>> >>> * In producing the WG report, the chair will be responsible for >>> designating each position as having one of the following >>> designations: * Rough consensus position - a position where a >>> small minority disagrees but most agree * Strong support but >>> significant opposition * Minority viewpoint >>> * 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 : * Send email to >>> the chair, copying the WG explaining why the decision is believed >>> to be in error. * 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. * 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. >>> >>> * 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. >>> >>> Milestone (dates to be updated if/when charter is approved) >>> >>> * With assistance from Staff, template for constituency comments >>> due 40 days after WG is initiated >>> >>> * Constituency statements due 70 days after WG is initiated >>> >>> * Final report to be released to GNSO council and for public >>> comment at 90 days >>> >>> Working Group chair(s): >>> >>> TBD >>> GNSO Council Liaison(s) to Working Group: >>> >>> TBD >>> Staff Coordinator >>> >>> Liz Glasser >>> >>> Subject Matter References: >>> - Issues report 25 March 2008 >>> - [SAC025]: Fast Flux Hosting and DNS (SAC025) (28 January 2008) >>> >>> Process References: >>> - Tutorial on IETF WGs >>> - Information on W3C working group processes >>> >>> Documents/Draft Documents Produced by the WG >>> TBD >>> >> >> >

1 0

Fwd: Charter for Fast Flux PDP WG
by Avri Doria May 28, 2008

May 28, 2008

Hi, Again, I sent the message from the wrong email address - I sent it from my university account. I hope that people noticed the Fast Flux motion in the Agenda and have read through it for tomorrow's discussion. Please read this note and think about the appointments mentioned in the note. Thanks and apologies for the unintentional lateness of this notice. a. Begin forwarded message: > From: Avri Doria <avri(a)ltu.se> > Date: 22 May 2008 16:02:38 EDT > To: Council GNSO <council(a)gnso.icann.org> > Subject: Charter for Fast Flux PDP WG > > Hi, > > At our last meeting, we voted on a motion to create a WG for the > purposes of proceeding with the work on the Fast Flux PDP. A > proposed charter was due to the Council by today. That charter can > be found on the Socialtext GNSO work space under [Fast Flux] (aka https://st.icann.org/gnso-council/index.cgi?fast_flux) > . I have also included a copy of that charter below. > > Discussion and, if at all possible, a vote on this charter is > scheduled for our meeting of 29 May. Prior discussion on the list > before then is encouraged so that any edits can be made early if > possible. > > Additionally, in reading through the charter you will note that > several roles are marked TBD. > > Specifically > > - a chair or co-chairs need to be appointed. The conception we have > had of this group, and working groups in general, is that the chair > or co-chairs, should _not_ be council members. I therefore look to > the council members to provide suitable candidates for us to discuss. > > - a council liaison who will act as the point of contact between the > WG and the council as described in the charter. In this case the > council will need to choose between whomever on the council > volunteers for this role. Though I do believe that council members > should be able to participate in WGs in their individual capacities > without being chosen as the liaison to the WG. > > (During the council meeting, I will ask whether the group whether we > want to go off recording while we discuss these staffing issues. In > the past we have decided to keep the call on the public record even > when discussing staff issues, and I am personally comfortable with > doing so again as long as we do so deliberately.) > > I look forward to your feed back on this charter. It is the first > approximation at some of the processes and procedures we may adopt > as part of the "improvements" process and is based on our successful > previous experiences with WGs. > > thanks > > a. > > > --- > > PDP Working group on Fast Flux Issues > > hereas Council has decided to launch a PDP to consider potential > policy development to address fast flux hosting; > > The GNSO Council RESOLVES: > > To form a Working Group of interested stakeholders and Constituency > representatives, to collaborate broadly with knowledgeable > individuals and organizations, in order to develop potential policy > options to curtail the criminal use of fast flux hosting. The WG is > also open to invited experts and to members of the ICANN advisory > committees whether acting in their own right or as representatives > of their AC. > Charter > > The Working Group initially shall consider the following questions: > > * Who benefits from fast flux, and who is harmed? > > * Who would benefit from cessation of the practice and who would > be harmed? > > * How are registry operators involved in fast flux hosting > activities? > > * How are registrars involved in fast flux hosting activities? > > * How are registrants affected by fast flux hosting? > > * How are Internet users affected by fast flux hosting? > > * What technical, e.g. changes to the way in which DNS updates > operate, and policy, e.g. changes to registry/registrar agreements > or rules governing permissible registrant behavior measures could be > implemented by registries and registrars to mitigate the negative > effects of fast flux? > > * What would be the impact (positive or negative) of establishing > limitations, guidelines, or restrictions on registrants, registrars > and/or registries with respect to practices that enable or > facilitate fast flux hosting? > > * What are some of the best practices available with regard to > protection from fast flux. > > * What areas of fast flux are in scope and out of scope for GNSO > policy making? > > The Working Group shall report back to Council within 90 days, with > a report discussing these questions and the range of possible > answers developed by the Working Group members. The Working Group > report also shall outline potential next steps for Council > deliberation. These next steps may include further work items for > the WG or policy recommendation for constituency and community > comment and review and for council deliberation > Working Group processes: > > While the development of guidelines for Working 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. Anyone > with a minority view will be invited to include a discussion in the > WG report. > > * In producing the WG report, the chair will be responsible for > designating each position as having one of the following > designations: * Rough consensus position - a position where a small > minority disagrees but most agree * Strong support but significant > opposition * Minority viewpoint > * 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 : * Send email to the > chair, copying the WG explaining why the decision is believed to be > in error. * 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. * 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. > > * 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. > > Milestone (dates to be updated if/when charter is approved) > > * With assistance from Staff, template for constituency comments > due 40 days after WG is initiated > > * Constituency statements due 70 days after WG is initiated > > * Final report to be released to GNSO council and for public > comment at 90 days > > Working Group chair(s): > > TBD > GNSO Council Liaison(s) to Working Group: > > TBD > Staff Coordinator > > Liz Glasser > > Subject Matter References: > - Issues report 25 March 2008 > - [SAC025]: Fast Flux Hosting and DNS (SAC025) (28 January 2008) > > Process References: > - Tutorial on IETF WGs > - Information on W3C working group processes > > Documents/Draft Documents Produced by the WG > TBD >

1 0

Volunteers for Front Running drafting group
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG May 28, 2008

May 28, 2008

Dear All, Reminder: The GNSO Council resolved, on 8 May 2008, to create a Front Running drafting team to look at questions such as: - How is the problem defined? - How prevalent is the problem? - Will the measures relating to domain tasting affect front running? - Are there rules within the RAA that can be used? The goal is to bring a recommendation to the council on whether to request an Issues report or more extensive research effort and to define the terms of the report. This team should bring its report by 7 June 2008 in time for deliberations in Paris or sooner if possible. Team is open to constituency members. Liaisons are invited to participate A mailing list has been created Front running drafting team <gnso-fr-dt(a)icann.org> with public archives: http://forum.icann.org/lists/gnso-fr-dt/ There is also a WIKI space available for the drafting group at: https://st.icann.org/gnso-council/index.cgi?front_running Background: The ALAC submitted a letter to the ICANN Board requesting it 'to establish a temporary narrowly-tailored policy as a stopgap until such time as the relevant policy-recommending ICANN Supporting Organisations can provide a comprehensive consensus policy solution' <http://gnso.icann.org/mailing-lists/archives/council/msg04857.html > The ICANN Board's disposition was that <http://www.icann.org/minutes/prelim-report-27mar08.htm > "The Chair determined that emergency action is not required today but the matter will be referred to the GNSO for additional information or policy development if necessary, but not an emergency action." Please let me know the constituency members who have volunteered to be on the drafting team, so that they can be subscribed to the mailing list. Let me know if you have any questions. Thanks so very much! Glen -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

2 1

ICANN Compliance system working to correct Whois and other issues
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG May 26, 2008

May 26, 2008

[To: council[at]gnso.icann.org; liaison6c[at]gnso.icann.org] [To: ga[at]gnso.icann.org; announce[at]gnso.icann.org] [To: regional-liaisons[at]icann.org] http://www.icann.org/announcements/announcement-23may08.htm "Worst Spam Offenders" Notified by ICANN Compliance system working to correct Whois and other issues 23 May 2008 In order to clarify the system for dealing with incorrect “Whois” domain name registration information, and deal with community concern, ICANN is releasing the following information regarding its compliance work. MARINA DEL REY, Calif.: ICANN has sent enforcement notices and notices of concern to certain registrars, including those reported this week as being the registrars for the majority of websites advertised in spam emails. Earlier this week, an investigation by KnujOn, widely reported online, publicly identified 10 registrars as being the companies used to register the majority of domain names that have since appeared in spam email messages. More than half of those registrars named had already been contacted by ICANN prior to publication of KnujOn’s report, and the remainder have since been notified following an analysis of other sources of data, including ICANN’s internal database. With tens of millions of domain names in existence, and tens of thousands changing hands each day, ICANN relies upon the wider Internet community to report and review what it believes to be inaccurate registration data for individual domains. To this end, a dedicated online system called the Whois Data Problem Report System (“WDPRS”) was developed in 2002 to receive and track such complaints.* "ICANN sends, on average, over 75 enforcement notices per month following complaints from the community. We also conduct compliance audits to determine whether accredited registrars and registries are adhering to their contractual obligations," explained Stacy Burnette, Director of Compliance at ICANN.** "Infringing domain names are locked and websites removed every week through this system." Although the majority of registrars offer excellent services and contribute to the highly competitive market for domains, ICANN’s compliance department has developed an escalation process to protect registrants and give registrars an opportunity to cure cited violations before ICANN commences the breach process. However, while registrars are responsible for investigating claims of Whois inaccuracy, it is not fair to assume a registrar that sponsors spam-generating domain names is affiliated with the spam activity. A distinction must be made between registrars and an end user who chooses to use a particular domain name for illegitimate purposes. "But if those registrars, including those publicly cited, do not investigate and correct alleged inaccuracies reported to ICANN, our escalation procedure can ultimately result in ICANN terminating their accreditation and preventing them from registering domain names," Ms Burnette said. [ends] * For more information on the WDPRS system, please review the April edition of the ICANN’s Contractual Compliance Newsletter, available at: http://www.icann.org/compliance/archive/compliance-newsletter-200805.html. ** Figures on notices sent out by ICANN are updated monthly and are available online and in a newsletter than anyone can subscribe to (subscribe to this and other newsletters at: http://www.icann.org/newsletter) -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0

pre-meeting chat between staff and chair/v-chair
by Avri Doria May 24, 2008

May 24, 2008

Hi, If we are going to have one of those chat between staff and the chair/ v-chair before this meeting it needs to be Monday or Tuesday if I am going to participate. it is strange but it seems like the entire Board meeting is about the GNSO. too bad we weren't able to move our meeting later but it would have been bad to lose participants because of that move. too bad they can't move an hour earlier - was that ever considered? thanks a.

2 1

Issues Report -Inter-Registrar Transfer Policy: Set A; “New IRTP Issues”
by GNSO.SECRETARIAT＠GNSO.ICANN.ORG May 23, 2008

May 23, 2008

Dear Councillors, Please view directly the GNSO Issues Report Inter-Registrar Transfer Policy: Set A; “New IRTP Issues” at: http://www.gnso.icann.org/issues/transfers/transfer-issues-report-set-a-23m… STATUS OF THIS DOCUMENT This is the Issues Report on Issue Set A; “New IRTP Issues”, regarding the Inter-Registrar Transfer Policy, produced by ICANN staff for submission to the GNSO Council on 23 May 2008. SUMMARY This report is submitted to the GNSO Council in response to the motion passed by the GNSO Council on 8 May 2008: “…Resolved that the Council asks the staff to produce an Issues Report of the Items listed under A - New IRTP Issues.” (see http://gnso.icann.org/drafts/transfer-wg-recommendations-pdp-groupings- 19mar08.pdf ).” This document is posted here: http://gnso.icann.org/policies/ here: http://gnso.icann.org/index.html and here: http://gnso.icann.org/issues/ Thank you. kind regards, Glen -- Glen de Saint Géry GNSO Secretariat - ICANN gnso.secretariat[at]gnso.icann.org http://gnso.icann.org

1 0