September 2011 - council - lists.icann.org

Joint SO/AC Working Group on New gTLD Applicant Support FINAL REPORT
by Glen de Saint Géry Sept. 15, 2011

Sept. 15, 2011

Dear All, The Joint SO/AC Working Group on New gTLD Applicant Support Final Report http://gnso.icann.org/drafts/jas-final-report-13sep11-en.pdf for convenient referencing is posted at: http://gnso.icann.org/ http://gnso.icann.org/drafts Thank you very much. Kind regards, Glen Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org<mailto:gnso.secretariat@gnso.icann.org> http://gnso.icann.org

1 0

RE: [council] Motion from the RrSG
by Alan Greenberg Sept. 15, 2011

Sept. 15, 2011

Agreed. There are still differences of opinion but they do not kick in on this one, so hopefully this will go through smoothly. Alan At 15/09/2011 10:46 AM, Tim Ruiz wrote: >To be clear, the only reason the last RAA revisions were done that way >is because Registrars agreed to it. There should be no confusion between >Consensus Policy issues and amendments to the RAA that do not fall with >those issues. We maintain that the RAA cannot be otherwise amended >without Registrar approval. But I hope we don't let that argument derail >what we are trying to do here. > > >Tim > > > -------- Original Message -------- > > Subject: RE: [council] Motion from the RrSG > > From: Alan Greenberg <alan.greenberg(a)mcgill.ca> > > Date: Thu, September 15, 2011 9:38 am > > To: Tim Ruiz <tim(a)godaddy.com> > > Cc: <council(a)gnso.icann.org> > > > > Further to my last note, in a discussion with the PDP-WT, I was > > reminded that the RAA language allows the RAA picket fence issues to > > be adopted by a 2/3 vote of the GNSO and then Board ratification. > > That is in fact how the last RAA revision was done. But I thought > > that there had been a general belief that in the future, the PDP > > process would be used. > > > > So I guess I over-reacted to Tim's initial note. If all parties agree > > that the RAA fast path is still valid, there is not an issue. > > > > Alan > > > > At 14/09/2011 07:29 PM, Alan Greenberg wrote: > > > > >Hadn't looked at like that but you are probably correct about it > > >being within the picket fence. > > > > > >However, I thought that the only way that something could become a > > >Consensus Policy was by going through the formal PDP process. Cases > > >such as this are exactly why I have been pushing for a "fast-path" > > >PDP where all parties seem to be in agreement at the start, but to > > >date, there is no such process on the books. > > > > > >Maybe this is the case that makes us re-think that. > > > > > >Alan > > > > > >At 14/09/2011 06:20 PM, Tim Ruiz wrote: > > >>Actually, while not definitive, IMO they appear to fall within 4.2.1 and > > >>possibly 4.2.6 and 4.2.8 of the RAA (section 4.2 defines the so-called > > >>picket fence.) So I believe we see these as becoming consensus policy as > > >>defined in section 4 of the RAA and would be binding on all registrars > > >>if Council approves with a supermajority and Board approves as well. > > >> > > >> > > >>Tim > > >> > > >> > -------- Original Message -------- > > >> > Subject: Re: [council] Motion from the RrSG > > >> > From: Alan Greenberg <alan.greenberg(a)mcgill.ca> > > >> > Date: Tue, September 13, 2011 3:16 pm > > >> > To: Tim Ruiz <tim(a)godaddy.com>,GNSO Council <council(a)gnso.icann.org> > > >> > > > >> > Tim, I applaud this action on behalf of the RrSG, but do have > > >> > questions regarding how the RrSG sees this being implemented. > > >> > > > >> > The content does not seem to be within the picket fence and so no PDP > > >> > is required. But the only means I am aware of for getting such rules > > >> > into the RAA is for the Board to approve them and then they kick in > > >> > on the next RAA renewal - up to 5 years away. On the last RAA change, > > >> > ICANN had to offer financial rewards to Registrars to get them to > > >> > sign onto the revised agreement (and last I heard there were still > > >> > some that have not). > > >> > > > >> > Do you envisage ICANN having to offer additional financial incentives > > >> > in this case, (and still wait up to 5 years for all Registrars to be > > >> > on board)? Or what else is proposed to actually get this implemented > > >> > in a more timely manner? > > >> > > > >> > Also, do you envisage that this is an obligation that registrars will > > >> > be obliged to pass on to their resellers? > > >> > > > >> > Alan > > >> > > > >> > At 13/09/2011 02:51 PM, Tim Ruiz wrote: > > >> > >The following motion (also attached as a doc file) is being made at > > >> > >the request of the RrSG. We feel the recommendations contained in it > > >> > >are requested and generally agreed as necessary by Law Enforcement > > >> > >Agencies (LEA), are supported by the GAC, and have not garnered any > > >> > >opposition from other SGs or Cs. > > >> > > > > >> > >Tim

1 0

RE: [council] Motion from the RrSG
by Alan Greenberg Sept. 15, 2011

Sept. 15, 2011

Thanks Tim. As I said in my note that crossed paths with yours, I had assumed that clause 4.3.1 was no longer going to be used, but it is still there and I am delighted to make use of it here. And in retrospect, there is no reason to change it is I suppose. A PDP is a valid way to enact Policy change, but for the RAA, it is not the only way. So sorry for raising alarms where they were not necessary. Alan At 15/09/2011 10:30 AM, Tim Ruiz wrote: >Alan, > >Please see section 4.3.1 of the RAA: >http://www.icann.org/en/registrars/ra-agreement-21may09-en.htm > >That was constructed because at the time of the original RAA no PDP >existed. Now that one does, and to the extent that it meets these >minimum requirements, a PDP may result in Consensus Policy. At some >point this section of the RAA may need to be updated, but right now, >with the exception of the report described in part (c), we feel our >motion would suffice to create Consensus Policy if approved by a >supermajority of the Council and then upheld by a vote of the Board. For >the report, the information exists but we may need to request Staff to >assist in pulling it together. > >That doesn't answer your question completely, but our focus is on the >motion immediately at hand as it pertains to establishing Consensus >Policy. We realize that some may have concerns about process here, and >we are certainly sensitive to that and open to considering a full PDP if >deemed necessary. > >Tim > > > -------- Original Message -------- > > Subject: RE: [council] Motion from the RrSG > > From: Alan Greenberg <alan.greenberg(a)mcgill.ca> > > Date: Wed, September 14, 2011 6:29 pm > > To: Tim Ruiz <tim(a)godaddy.com> > > Cc: <council(a)gnso.icann.org> > > > > Hadn't looked at like that but you are probably correct about it > > being within the picket fence. > > > > However, I thought that the only way that something could become a > > Consensus Policy was by going through the formal PDP process. Cases > > such as this are exactly why I have been pushing for a "fast-path" > > PDP where all parties seem to be in agreement at the start, but to > > date, there is no such process on the books. > > > > Maybe this is the case that makes us re-think that. > > > > Alan > > > > At 14/09/2011 06:20 PM, Tim Ruiz wrote: > > >Actually, while not definitive, IMO they appear to fall within 4.2.1 and > > >possibly 4.2.6 and 4.2.8 of the RAA (section 4.2 defines the so-called > > >picket fence.) So I believe we see these as becoming consensus policy as > > >defined in section 4 of the RAA and would be binding on all registrars > > >if Council approves with a supermajority and Board approves as well. > > > > > > > > >Tim > > > > > > > -------- Original Message -------- > > > > Subject: Re: [council] Motion from the RrSG > > > > From: Alan Greenberg <alan.greenberg(a)mcgill.ca> > > > > Date: Tue, September 13, 2011 3:16 pm > > > > To: Tim Ruiz <tim(a)godaddy.com>,GNSO Council <council(a)gnso.icann.org> > > > > > > > > Tim, I applaud this action on behalf of the RrSG, but do have > > > > questions regarding how the RrSG sees this being implemented. > > > > > > > > The content does not seem to be within the picket fence and so no PDP > > > > is required. But the only means I am aware of for getting such rules > > > > into the RAA is for the Board to approve them and then they kick in > > > > on the next RAA renewal - up to 5 years away. On the last RAA change, > > > > ICANN had to offer financial rewards to Registrars to get them to > > > > sign onto the revised agreement (and last I heard there were still > > > > some that have not). > > > > > > > > Do you envisage ICANN having to offer additional financial incentives > > > > in this case, (and still wait up to 5 years for all Registrars to be > > > > on board)? Or what else is proposed to actually get this implemented > > > > in a more timely manner? > > > > > > > > Also, do you envisage that this is an obligation that registrars will > > > > be obliged to pass on to their resellers? > > > > > > > > Alan > > > > > > > > At 13/09/2011 02:51 PM, Tim Ruiz wrote: > > > > >The following motion (also attached as a doc file) is being made at > > > > >the request of the RrSG. We feel the recommendations contained in it > > > > >are requested and generally agreed as necessary by Law Enforcement > > > > >Agencies (LEA), are supported by the GAC, and have not garnered any > > > > >opposition from other SGs or Cs. > > > > > > > > > >Tim

1 0

RE: [council] Motion from the RrSG
by Tim Ruiz Sept. 15, 2011

Sept. 15, 2011

To be clear, the only reason the last RAA revisions were done that way is because Registrars agreed to it. There should be no confusion between Consensus Policy issues and amendments to the RAA that do not fall with those issues. We maintain that the RAA cannot be otherwise amended without Registrar approval. But I hope we don't let that argument derail what we are trying to do here. Tim > -------- Original Message -------- > Subject: RE: [council] Motion from the RrSG > From: Alan Greenberg <alan.greenberg(a)mcgill.ca> > Date: Thu, September 15, 2011 9:38 am > To: Tim Ruiz <tim(a)godaddy.com> > Cc: <council(a)gnso.icann.org> > > Further to my last note, in a discussion with the PDP-WT, I was > reminded that the RAA language allows the RAA picket fence issues to > be adopted by a 2/3 vote of the GNSO and then Board ratification. > That is in fact how the last RAA revision was done. But I thought > that there had been a general belief that in the future, the PDP > process would be used. > > So I guess I over-reacted to Tim's initial note. If all parties agree > that the RAA fast path is still valid, there is not an issue. > > Alan > > At 14/09/2011 07:29 PM, Alan Greenberg wrote: > > >Hadn't looked at like that but you are probably correct about it > >being within the picket fence. > > > >However, I thought that the only way that something could become a > >Consensus Policy was by going through the formal PDP process. Cases > >such as this are exactly why I have been pushing for a "fast-path" > >PDP where all parties seem to be in agreement at the start, but to > >date, there is no such process on the books. > > > >Maybe this is the case that makes us re-think that. > > > >Alan > > > >At 14/09/2011 06:20 PM, Tim Ruiz wrote: > >>Actually, while not definitive, IMO they appear to fall within 4.2.1 and > >>possibly 4.2.6 and 4.2.8 of the RAA (section 4.2 defines the so-called > >>picket fence.) So I believe we see these as becoming consensus policy as > >>defined in section 4 of the RAA and would be binding on all registrars > >>if Council approves with a supermajority and Board approves as well. > >> > >> > >>Tim > >> > >> > -------- Original Message -------- > >> > Subject: Re: [council] Motion from the RrSG > >> > From: Alan Greenberg <alan.greenberg(a)mcgill.ca> > >> > Date: Tue, September 13, 2011 3:16 pm > >> > To: Tim Ruiz <tim(a)godaddy.com>,GNSO Council <council(a)gnso.icann.org> > >> > > >> > Tim, I applaud this action on behalf of the RrSG, but do have > >> > questions regarding how the RrSG sees this being implemented. > >> > > >> > The content does not seem to be within the picket fence and so no PDP > >> > is required. But the only means I am aware of for getting such rules > >> > into the RAA is for the Board to approve them and then they kick in > >> > on the next RAA renewal - up to 5 years away. On the last RAA change, > >> > ICANN had to offer financial rewards to Registrars to get them to > >> > sign onto the revised agreement (and last I heard there were still > >> > some that have not). > >> > > >> > Do you envisage ICANN having to offer additional financial incentives > >> > in this case, (and still wait up to 5 years for all Registrars to be > >> > on board)? Or what else is proposed to actually get this implemented > >> > in a more timely manner? > >> > > >> > Also, do you envisage that this is an obligation that registrars will > >> > be obliged to pass on to their resellers? > >> > > >> > Alan > >> > > >> > At 13/09/2011 02:51 PM, Tim Ruiz wrote: > >> > >The following motion (also attached as a doc file) is being made at > >> > >the request of the RrSG. We feel the recommendations contained in it > >> > >are requested and generally agreed as necessary by Law Enforcement > >> > >Agencies (LEA), are supported by the GAC, and have not garnered any > >> > >opposition from other SGs or Cs. > >> > > > >> > >Tim

1 0

RE: [council] Motion from the RrSG
by Alan Greenberg Sept. 15, 2011

Sept. 15, 2011

Hadn't looked at like that but you are probably correct about it being within the picket fence. However, I thought that the only way that something could become a Consensus Policy was by going through the formal PDP process. Cases such as this are exactly why I have been pushing for a "fast-path" PDP where all parties seem to be in agreement at the start, but to date, there is no such process on the books. Maybe this is the case that makes us re-think that. Alan At 14/09/2011 06:20 PM, Tim Ruiz wrote: >Actually, while not definitive, IMO they appear to fall within 4.2.1 and >possibly 4.2.6 and 4.2.8 of the RAA (section 4.2 defines the so-called >picket fence.) So I believe we see these as becoming consensus policy as >defined in section 4 of the RAA and would be binding on all registrars >if Council approves with a supermajority and Board approves as well. > > >Tim > > > -------- Original Message -------- > > Subject: Re: [council] Motion from the RrSG > > From: Alan Greenberg <alan.greenberg(a)mcgill.ca> > > Date: Tue, September 13, 2011 3:16 pm > > To: Tim Ruiz <tim(a)godaddy.com>,GNSO Council <council(a)gnso.icann.org> > > > > Tim, I applaud this action on behalf of the RrSG, but do have > > questions regarding how the RrSG sees this being implemented. > > > > The content does not seem to be within the picket fence and so no PDP > > is required. But the only means I am aware of for getting such rules > > into the RAA is for the Board to approve them and then they kick in > > on the next RAA renewal - up to 5 years away. On the last RAA change, > > ICANN had to offer financial rewards to Registrars to get them to > > sign onto the revised agreement (and last I heard there were still > > some that have not). > > > > Do you envisage ICANN having to offer additional financial incentives > > in this case, (and still wait up to 5 years for all Registrars to be > > on board)? Or what else is proposed to actually get this implemented > > in a more timely manner? > > > > Also, do you envisage that this is an obligation that registrars will > > be obliged to pass on to their resellers? > > > > Alan > > > > At 13/09/2011 02:51 PM, Tim Ruiz wrote: > > >The following motion (also attached as a doc file) is being made at > > >the request of the RrSG. We feel the recommendations contained in it > > >are requested and generally agreed as necessary by Law Enforcement > > >Agencies (LEA), are supported by the GAC, and have not garnered any > > >opposition from other SGs or Cs. > > > > > >Tim

1 1

RE: [council] Motion from the RrSG
by Tim Ruiz Sept. 15, 2011

Sept. 15, 2011

Alan, Please see section 4.3.1 of the RAA: http://www.icann.org/en/registrars/ra-agreement-21may09-en.htm That was constructed because at the time of the original RAA no PDP existed. Now that one does, and to the extent that it meets these minimum requirements, a PDP may result in Consensus Policy. At some point this section of the RAA may need to be updated, but right now, with the exception of the report described in part (c), we feel our motion would suffice to create Consensus Policy if approved by a supermajority of the Council and then upheld by a vote of the Board. For the report, the information exists but we may need to request Staff to assist in pulling it together. That doesn't answer your question completely, but our focus is on the motion immediately at hand as it pertains to establishing Consensus Policy. We realize that some may have concerns about process here, and we are certainly sensitive to that and open to considering a full PDP if deemed necessary. Tim > -------- Original Message -------- > Subject: RE: [council] Motion from the RrSG > From: Alan Greenberg <alan.greenberg(a)mcgill.ca> > Date: Wed, September 14, 2011 6:29 pm > To: Tim Ruiz <tim(a)godaddy.com> > Cc: <council(a)gnso.icann.org> > > Hadn't looked at like that but you are probably correct about it > being within the picket fence. > > However, I thought that the only way that something could become a > Consensus Policy was by going through the formal PDP process. Cases > such as this are exactly why I have been pushing for a "fast-path" > PDP where all parties seem to be in agreement at the start, but to > date, there is no such process on the books. > > Maybe this is the case that makes us re-think that. > > Alan > > At 14/09/2011 06:20 PM, Tim Ruiz wrote: > >Actually, while not definitive, IMO they appear to fall within 4.2.1 and > >possibly 4.2.6 and 4.2.8 of the RAA (section 4.2 defines the so-called > >picket fence.) So I believe we see these as becoming consensus policy as > >defined in section 4 of the RAA and would be binding on all registrars > >if Council approves with a supermajority and Board approves as well. > > > > > >Tim > > > > > -------- Original Message -------- > > > Subject: Re: [council] Motion from the RrSG > > > From: Alan Greenberg <alan.greenberg(a)mcgill.ca> > > > Date: Tue, September 13, 2011 3:16 pm > > > To: Tim Ruiz <tim(a)godaddy.com>,GNSO Council <council(a)gnso.icann.org> > > > > > > Tim, I applaud this action on behalf of the RrSG, but do have > > > questions regarding how the RrSG sees this being implemented. > > > > > > The content does not seem to be within the picket fence and so no PDP > > > is required. But the only means I am aware of for getting such rules > > > into the RAA is for the Board to approve them and then they kick in > > > on the next RAA renewal - up to 5 years away. On the last RAA change, > > > ICANN had to offer financial rewards to Registrars to get them to > > > sign onto the revised agreement (and last I heard there were still > > > some that have not). > > > > > > Do you envisage ICANN having to offer additional financial incentives > > > in this case, (and still wait up to 5 years for all Registrars to be > > > on board)? Or what else is proposed to actually get this implemented > > > in a more timely manner? > > > > > > Also, do you envisage that this is an obligation that registrars will > > > be obliged to pass on to their resellers? > > > > > > Alan > > > > > > At 13/09/2011 02:51 PM, Tim Ruiz wrote: > > > >The following motion (also attached as a doc file) is being made at > > > >the request of the RrSG. We feel the recommendations contained in it > > > >are requested and generally agreed as necessary by Law Enforcement > > > >Agencies (LEA), are supported by the GAC, and have not garnered any > > > >opposition from other SGs or Cs. > > > > > > > >Tim

1 0

AW: [council] RE: Motions on the Wiki page
by KnobenW＠telekom.de Sept. 15, 2011

Sept. 15, 2011

Hi, Maybe it helps to use a lower case "joint" (jWG) until the frame for (J)WGs is fixed - or is this even more subtle? If not I'd like to propose it as a friendly amendment and second the motion. Kind regards Wolf-Ulrich -----Ursprüngliche Nachricht----- Von: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] Im Auftrag von Jonathan Robinson Gesendet: Mittwoch, 14. September 2011 16:24 An: 'Rosemary Sinclair'; 'Glen de Saint Géry'; 'GNSO Council List' Betreff: RE: [council] RE: Motions on the Wiki page Hi Rosemary, The draft charter refers to a (GNSO) WG yet the motion refers to a JWG. Am I missing an obvious subtlety here? Thanks, Jonathan -----Original Message----- From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Rosemary Sinclair Sent: 13 September 2011 21:38 To: Glen de Saint Géry; GNSO Council List Subject: [council] RE: Motions on the Wiki page Hi all I'd welcome any comments on the Motion I have proposed... And a seconder for the Motion! Cheers Rosemary ________________________________________ From: owner-council(a)gnso.icann.org [owner-council(a)gnso.icann.org] On Behalf Of Glen de Saint Géry [Glen(a)icann.org] Sent: Tuesday, September 13, 2011 9:17 AM To: GNSO Council List Subject: [council] Motions on the Wiki page Dear Councillors, Please find the motions proposed by: - Wolf-Ulrich Knoben and seconded by Stéphane van Gelder on the revision of the GNSO Council Operating Procedures Relating to Proxy Voting - Rosemary Sinclair to create a joint working group on consumer choice, competition and innovation - Zahid Jamil to Address the Remaining Registration Abuse Policies Working Group Recommendations On the Wiki page: https://community.icann.org/display/gnsocouncilmeetings/Motions+22+September +2011 Thank you. Kind regards, Glen Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org __________ Information from ESET NOD32 Antivirus, version of virus signature database 6461 (20110913) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

2 1

RE: AW: [council] RE: Motions on the Wiki page
by Tim Ruiz Sept. 15, 2011

Sept. 15, 2011

I am not convinced it is a good idea to do this as a JWG in this manner. I thought we were moving toward a GNSO WG, which of course are always open to all regardless of SO or AC affiliation. I think that is the quickest way to get Council agreement on this work AND to get it completed. JWGs are still controversial for many of us and we need to complete our work on that before initiating any further JWGs or CWGs. Tim > -------- Original Message -------- > Subject: AW: [council] RE: Motions on the Wiki page > From: KnobenW(a)telekom.de > Date: Thu, September 15, 2011 5:02 am > To: <jonathan.robinson(a)ipracon.com>, <rosemary.sinclair(a)unsw.edu.au>, > <Glen(a)icann.org>, <council(a)gnso.icann.org> > > Hi, > > Maybe it helps to use a lower case "joint" (jWG) until the frame for (J)WGs is fixed - or is this even more subtle? > If not I'd like to propose it as a friendly amendment and second the motion. > > > Kind regards > Wolf-Ulrich > > > > -----Ursprüngliche Nachricht----- > Von: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] Im Auftrag von Jonathan Robinson > Gesendet: Mittwoch, 14. September 2011 16:24 > An: 'Rosemary Sinclair'; 'Glen de Saint Géry'; 'GNSO Council List' > Betreff: RE: [council] RE: Motions on the Wiki page > > > Hi Rosemary, > > The draft charter refers to a (GNSO) WG yet the motion refers to a JWG. > > Am I missing an obvious subtlety here? > > Thanks, > > > Jonathan > > -----Original Message----- > From: owner-council(a)gnso.icann.org [mailto:owner-council@gnso.icann.org] On > Behalf Of Rosemary Sinclair > Sent: 13 September 2011 21:38 > To: Glen de Saint Géry; GNSO Council List > Subject: [council] RE: Motions on the Wiki page > > > Hi all > > I'd welcome any comments on the Motion I have proposed... > > And a seconder for the Motion! > > Cheers > > Rosemary > ________________________________________ > From: owner-council(a)gnso.icann.org [owner-council(a)gnso.icann.org] On Behalf > Of Glen de Saint Géry [Glen(a)icann.org] > Sent: Tuesday, September 13, 2011 9:17 AM > To: GNSO Council List > Subject: [council] Motions on the Wiki page > > Dear Councillors, > > Please find the motions proposed by: > - Wolf-Ulrich Knoben and seconded by Stéphane van Gelder on the revision of > the GNSO Council Operating Procedures Relating to Proxy Voting > - Rosemary Sinclair to create a joint working group on consumer choice, > competition and innovation > - Zahid Jamil to Address the Remaining Registration Abuse Policies Working > Group Recommendations > > On the Wiki page: > https://community.icann.org/display/gnsocouncilmeetings/Motions+22+September > +2011 > > Thank you. > Kind regards, > > Glen > > > Glen de Saint Géry > GNSO Secretariat > gnso.secretariat(a)gnso.icann.org > http://gnso.icann.org > > > > > > __________ Information from ESET NOD32 Antivirus, version of virus signature > database 6461 (20110913) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com

3 2

Safe and Secure New gTLDs: ICANN Seeks Back-up Registry Operators
by Glen de Saint Géry Sept. 15, 2011

Sept. 15, 2011

http://www.icann.org/en/announcements/announcement-2-14sep11-en.htm Safe and Secure New gTLDs: ICANN Seeks Back-up Registry Operators (Emergency Back-End Registry Operators or "EBEROs") 14 September 2011 ICANN is issuing today a Request for Information (RFI)<http://www.icann.org/en/documents/rfps/ebero-rfi-14sep11-en.pdf> [PDF, 660 KB] to identify potential Emergency Back-End Registry Operators (EBERO). One of ICANN's core missions is to preserve the operational security and stability of the Internet while also supporting open competition. With the upcoming launch of the New generic Top-Level Domain (New gTLD) program, the Internet will see a number of new gTLD registry operators. Although all applicants must meet technical, operational and financial requirements (see the gTLD Applicant Guidebook - http://www.icann.org/en/topics/new-gtlds/dag-en.htm) the community developed new gTLD program includes provision for a backup process. The EBERO is designed to be activated should a registry operator require assistance to sustain critical registry functions for a period of time or in the case of transition for one registry operator to another. Candidates are expected to meet the requirements outlined in the RFI, which requires, for example, at least three years of experience in operating Domain Name services (DNS) and one year of experience operating Registration Data Directory Services (RDDS) and Extensible Provisioning Protocol (EPP) services. Besides the technical requirements, ICANN seeks candidates from geographically diverse regions in order to provide local service to registries in all regions and provide alternate sites in case of local disasters. ICANN is looking forward to receiving comprehensive information from the potential candidates. Negotiations with certain respondents to the RFI that provide comprehensive information will be initiated for the purpose of creating process details and entering into an agreement to provide backend services. The deadline for responses is November 30, 2011 at 23:59 UTC. Please direct your information to ebero(a)icann.org<mailto:ebero@icann.org>. Responses after the deadline will not be considered. RFI activities schedule at a glance: Request for proposals issued by ICANN 14 September 2011 Respondents' Q&A - Teleconference On or about 16 November 2011 Written proposals due 30 November 2011 - 23:59 UTC 1. What is a registry? A "Registry" is the authoritative, master database of all domain names registered in each Top-Level Domain. The registry operator keeps the master database and also generates the "zone file" which allows computers to route Internet traffic to and from top-level domains anywhere in the world. 2. What is an Emergency Operator? Emergency Operator or Back-End Registry Operator is an organization that has partnered with ICANN to provide registry services in case another registry is unable to operate. The emergency operators will be selected by ICANN based on the criteria outlined in the RFI. 3. What happens when a gTLD registry operation fail either financially or due a technical emergency? If an emergency occurs, and a Registry is unable to provide critical services, it will be the function of the Emergency Operator to ensure the continuity of the services. This provider emergency transition process is managed by ICANN and requires multiple providers to be available to take on the function in case one provider is not able to timely take the operation or if there is a conflict of interest. 4. What are the critical registry functions? Functions that are critical to the operation of a gTLD registry (i.e., those provided by the EBERO) are: * Domain Names System (DNS) resolution; * Domain Name System Security Extensions (DNSSEC) properly signed zone (if DNSSEC is offered by the registry); * Shared Registration System (SRS), usually by means of the Extensible Provisioning Protocol (EPP); * Registration Data Directory Services (RDDS), e.g., WHOIS provided over both port 43 and through a web based service; * Registry Data Escrow. 5. What kind of information is ICANN requesting and who should respond? Respondents should be parties interested in committing themselves as potential Emergency Back-End Registry Operators. The RFI covers numerous areas, but respondents should be prepared to discuss the following: * Capabilities and experience in the critical registry functions; * Registry Transition concepts, experience, SLAs, and use cases; * Pricing models for providing critical registry functions; * Profile of the respondents organization, leadership and resources. Background In April 2009, ICANN published the ICANN gTLD Registry Continuity Plan - http://www.icann.org/en/registries/continuity/. This document depicts a gTLD Registry Continuity Framework developed in collaboration with experienced gTLD, ccTLD registries and members of the technical community. The overall goals of ICANN's gTLD Registry Continuity Framework are: 1. the protection of existing registrants; and 2. to ensure confidence in the DNS. The Registry Continuity framework recognized the need for a prescribed ability to continue services in the event of a Registry Operator failure. It introduced the concept of a Back-End Operator and the intrinsic complications in a single back-up operator supporting all existing capabilities of different registry models. In view of those complications, the concept of identifying base level "critical functions", required to maintain the minimum operating services of a Top Level Domain, was established and defined. In May 2010 ICANN published a New Top-Level Domain Explanatory Memorandum "gTLD Registry Transition Processes Model" (RyTP) - http://www.icann.org/en/topics/new-gtlds/registry-transition-processes-clea… [PDF, 747 KB]. This document further elaborates on the concept of critical functions required for maintaining Top-Level Domain services and discusses the types of transitions between one Registry Operator and another. The concept of the Emergency Back-End Registry Operator was also introduced to support the TLD critical functions of failing Registry Operators, when there is no immediate assigned successor Registry Operator. Links to Relevant Information: * New gTLD Program: http://www.icann.org/en/topics/new-gtld-program.htm * gTLD Registry Continuity Document Archive: http://www.icann.org/en/registries/continuity/archive-en.htm Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

ECO reception in Dakar
by Stéphane Van Gelder Sept. 15, 2011

Sept. 15, 2011

Councillors, Thomas Rickert, one of our new NCAs, works with the german association ECO to promote outreach about ICANN and the Internet. ECO are organizing a reception for its members in Dakar (I understand they do so at every ICANN meeting) and Thomas has asked me to come and say a few words about the GNSO and the projects we are currently working on. I want to thank Thomas for this opportunity to do some more informative outreach about what our SOs does and how it works, therefore helping people in the community be more aware of what goes on within ICANN's policy-making body for gTLDs. Thanks, Stéphane

1 0