June 2010 - council - lists.icann.org

FW: Joint Working Group to consider concept of DNS CERT
by Gomes, Chuck June 11, 2010

June 11, 2010

I forwarded the following message to the Council the yesterday and added the topic to our agenda for our meeting under Other Business. Unfortunately, as we ran out of time, I failed to cover it. My intent was to simply ask if anyone objected to considering the formation of a WG as described by Chris and if not, to request volunteers to start working on a possible charter with volunteers from the ccNSO. So I will ask those questions now: 1. Does anyone object to considering the formation of such a WG? Note that we would not make an official decision to support such a WG until after we see a draft charter. If anyone objects, please communicate your objection not later than next Wednesday, 16 June. 2. Assuming there is no opposition, who would like to volunteer for the charter drafting team? Note that this is not a request for volunteers for what might eventually be a WG, but only for a charter DT. Regarding question 2, there have already been some volunteers in response to my message yesterday: * Terry Davis (NCA) * Rafik Damik (NCSG) * Greg Aaron (RySG, Afilias) * Kathy Kleiman (RySG, PIR) * Keith Drazek (RySG, VeriSign). If anyone else wants to volunteer, please communicate your interest on this list not later than next Wednesday, 16 June. We will then communicate the names and contact information to the ccNSO. Thanks, Chuck From: Chris Disspain [mailto:ceo@auda.org.au] Sent: Tuesday, June 08, 2010 9:54 PM To: Gomes, Chuck Cc: 'Cheryl Langdon-Orr' Subject: Joint Working Group to consider concept of DNS CERT Chuck, In our conversation last week we discussed the possibility of the gNSO and ccNSO (along with other relevant ACs and independent experts) setting up the working group contemplated in the joint Chair's letter to ICANN of 25 March 2010 as soon as possible. I put this proposal to the ccNSO council on our call of 8 June and confirm that the council has agreed that in the event of the proposal also being agreed by the gNSO council, a small joint drafting team should work before Brussels to draft the charter for the establishment of a Working Group comprising representatives of ICANN's Security and Stability Advisory Committee, Root Server System Advisory Committee, GAC, ALAC, CERT operators and ccTLD and gTLD managers to draw upon their collective expertise and to solicit their input on: * the broad concept of a DNS-CERT; * the current work being undertaken to mitigate DNS-related threats; * the actual level, frequency and severity of these threats; * the gaps (if any) in the current security response to DNS issues; * whether or not a DNS-CERT is a proposal they support; and * if so, the logistics of the proposal. The goal would be to have the charter approved by the ccNSO and gNSO in Brussels if possible so that we can announce the formation of the working group. I'm guessing that formally the working group will need to be a joint gNSO ccNSO group (as the 2 relevant supporting organisations that can actually make policy) with the charter mandating the involvement of the relevant ACs and outside experts. In the event that the gNSO council does approve the proposal then the action items will be a) to call for some volunteers to do the drafting along with Bart Boswinkel as ccNSO staff and an equivalent gNSO person and b) to approach the other ACs to inform them that this is occurring. I understand your council meets on 10 June 2010 and look forward to hearing from you regarding your discussions. Cheers, Chris Disspain | Chief Executive Officer .au Domain Administration Ltd T: 1300 732 929 <tel:1300%20732%20929> | F: 03 8341 4112 <tel:03%208341%204112> E: ceo(a)auda.org.au | W:www.auda.org.au <http://www.auda.org.au/> auDA - The Australian Domain Name Administrator Important Notice - This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately. Please consider the environment before printing this email. __________ Information from ESET Smart Security, version of virus signature database 5183 (20100608) __________ The message was checked by ESET Smart Security. http://www.eset.com

4 5

FW: [soac-discussion] FW: Communication with ACSO on the next RTs
by Gomes, Chuck June 11, 2010

June 11, 2010

I sent this message to Janis regarding the composition of the AoC RTs. Chuck From: Gomes, Chuck Sent: Friday, June 11, 2010 11:00 AM To: Janis Karklins; soac-discussion(a)icann.org Cc: 'Rod Beckstrom'; 'Donna Austin'; 'Olof Nordling' Subject: RE: [soac-discussion] FW: Communication with ACSO on the next RTs Janis, After fairly extensive discussion on the GNSO Council list and additional discussion in our Council meeting yesterday, the GNSO feels very strongly that it is important to have four representatives on each of the RTs. I have included a sampling of some of the comments and rationale provided by various Councilors below. Note that most of these comments were reinforced by multiple Councilors and that there was overall agreement in the Council meeting for the position. Chuck General Comments * I'm not sure that an additional 2 GNSO reps will be detrimental to efficiency, and I should think it would actually add to the credibility of the process - which leaves "budgetary limitations" as the remaining (relatively unconvincing) reason. * It seems to me that the ramifications of the selectors rejecting GNSO input as to participant number are potentially significant. In particular, the irony of doing so while the accountability and transparency review is underway is pretty amazing. I think that would play pretty well (against ICANN, that is) in a number of important fora. * It'd be a lot easier if they'd just default to four across the board in order to ensure community representation and diverse skill sets at the table, rather than turning RT size into a needless source of angst. * It is perfectly reasonable to allow one seat each to the SSAC, GAC, and ASO. But I think it's totally implausible to assume a well represented RT with only two for the GNSO and one each for the ccNSO and the ALAC. I believe we make a very strong statement insisting that each of those are doubled - four for the GNSO (one for each SG, no less), two each for the ccNSO and the ALAC due to the size of their memberships. That would make the RT 14 members, and that is certainly workable and more realistic. SSR RT * All three (SSR) are already huge issues and will directly affect all the rollout and use of TLD's, IDN_TLDs, and ccTLDs and some of the issues that could be coming would include: - Punycode storage of IDN names - Neither any human nor most existing security mechanisms (anti-virus, firewalls, etc) can read it directly. It is the main reason you need "standard script" usage. - DNSSec - Can it and should it be pushed to all TLDs? (After a demo of DNS hacks a couple weeks back, I'm not sure I will ever trust a wireless hotspot fully again.) - DNSSec - Credentials - Key distribution chains and processes, rollover mechanisms, and there will likely be some of revocation process needed for bad behavior. - DNSSec - Operational issues yet to be determined too. DNSSec generates a 30x increase in response traffic for instance plus signature processing overhead. - Network management systems likewise will likely have initial issues with IDNs too. - Increased discussions of "network cyber identity requirements" and how these might work in an IDN environment. - Routing reliability as IPv6 vastly increases the route table sizes - IPv6 reachability and initial usage rollouts. (Outside of Microsoft, I could not say that anyone on the globe has a large scale IPv6 infrastructure working yet.) - New "whois" issues that could be created by fact that more, maybe most, IPv6 addresses will be indirectly assigned through an ISP to the end user or organization rather than directly assigned via IANA and the RIRs. * From an operational point of view, with implementation of TLDs, ccTLDs, IDN_TLDs, DNSSec, and IPv6 plus the issues with route stability and huge growth in cybercrime; one could reasonably expect that many unseen/unknown operational issues will affect GNSO plans and policies. (and certainly keep the SSR busy!) * The economies and critical infrastructure (communications, power, financial, etc) of at least 50 nations around the globe are completely tied to the security, stability, and reliability of the Internet so SSR issues are considered very carefully by most governments. * The Commercial SG provides combined expertise in technical, operational and legal respect of security aspects of the DNS system. Whois RT * Whereas Internet users across the whole ICANN community are impacted by Whois policy, I don't think there is any doubt that GNSO constituents are impacted the most. It is gTLD registrants whose data is displayed and used. It is gTLD contracted parties who are required to implement Whois and who best understand the customer service and operational issues related to Whois offerings. It is commercial gTLD registrants whose businesses are affected when IP rights are violated. It is noncommercial users who have most often pointed out the need for privacy of Whois information and noncommercial organizations that are impacted in similar ways as commercial businesses. * In addition, because of the GNSO's long and belabored Whois policy development history and varied Whois operational offerings, the GNSO has the best source of Whois experts from various points of view. There is also good evidence that each SG provides a unique area of expertise and represents different points of view with regard to Whois policy. * Whois is one of the few areas where people who are generally like-minded can have VERY different positions. * There really has to be four for WHOIS, the perspectives of the SGs are just too variable for any two to represent the others, and the whole process could become a focal point of controversy. * I strongly oppose accepting only two seats on the Whois. New gTLDs RT * Similar arguments could be made for this future RT. From: owner-soac-discussion(a)icann.org [mailto:owner-soac-discussion@icann.org] On Behalf Of Janis Karklins Sent: Friday, June 04, 2010 1:50 PM To: soac-discussion(a)icann.org Cc: 'Rod Beckstrom'; 'Donna Austin'; 'Olof Nordling' Subject: [soac-discussion] FW: Communication with ACSO on the next RTs Dear colleagues On behalf of Selectors I would like to propose that the size and composition of the two next review teams would be as follows: Security WHOIS GAC, including the Chair 2 1 GNSO 2 2 ccNSO 2 1 ALAC 2 1 SSAC 1 1 RSSAC 1 ASO 1 1 Independent expert 1-2 2 (law enforcement/privacy experts) CEO 1 1 13-14 10 I understand that your initial suggestions/requests were not fully accommodated, but for the sake of efficiency, credibility of the process, budgetary limitations Selectors have developed this proposal. If we would take into account all wishes, the RT size would be over 20 which in Selectors' view is not credible option. I hope that proposal will be equally unacceptable for everybody. I would appreciate your comments or expression of non-objection in coming week. Only after assessment of the violence of your opposition the Selectors will make their proposal (in present form or modified) public. Best regards JK

2 2

ccNSO - Update New councillor
by Olga Cavalli June 11, 2010

June 11, 2010

Hi, Fernando Espana (.us) has been elected to the ccNSO council in the North American region to replace Keith Drazek. Regards, Olga

1 0

Motion and Document Deadline - Tuesady 15 June 2010
by Glen de Saint Géry June 11, 2010

June 11, 2010

Dear Councillors, As required in the GNSO Operating Procedures, motions and reports for consideration in the Brussels Open Council meeting 23 June 2010 are due not later than 8 days in advance of that meeting, that is, Tuesday, 15 June 2010. Thank you. Kind regards, Glen Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

GNSO Council Resolutions 10 June 2010
by Glen de Saint Géry June 11, 2010

June 11, 2010

Dear All, Ahead of the official Council minutes, the following resolution was passed during the Council meeting on Thursday, 10 June 2010. Please let me know if you have any questions. Thank you. Kind regards, Glen Proposed Motion - New gTLD Recommendation (as amended June 2 & 10 June) Made by: Edmon Chung Seconded by: Rafik Dammak Note: The original motion was discussed in the Council meeting on 20 May and deferred to 10 June. In making the amended motion, Edmon submitted a redline version to the Council list on 2 June 2010 (http://gnso.icann.org/mailing-lists/archives/council/msg08962.html) and Rafik accepted the amendment as friendly on 4 June 2010 (http://gnso.icann.org/mailing-lists/archives/council/msg09000.html) WHEREAS: · The Draft Applicant Guidebook, Version 4 does not include an Extended Review option for strings that fail the initial evaluation for confusing similarity and likelihood to confuse; · The GNSO Council recognizes that time is of the essence in sending feedback to ICANN staff on the Draft Applicant Guidebook; · The IDNG Drafting Team established by the GNSO Council has discussed various circumstances where applicants for strings that may be designated as confusingly similar in the initial evaluation may be able to present a case showing that the string is not detrimentally similar to another string; · The GNSO Council in Recommendation #2 on the GNSO Final Report on the Introduction of New gTLDs in September 2007 intended to prevent confusing and detrimental similarity and not similarity that could serve the users of the Internet; RESOLVED: · A 21-day public comment period be opened not later than 11 June 2010 regarding a proposal to send the following letter to Kurt Pritz (with copy to the ICANN Board), requesting that Module 2 in the next version of the Draft Applicant Guidebook regarding "Outcomes of the String Similarity Review" be amended to allow applicants to request an Extended Review under applicable terms similar to those provided for other issues such as "DNS Stability: String Review Procedure". · ICANN Staff prepare a summary and analysis of the public comments not later than 6 July 2010. · The GNSO Council takes action in its meeting of 15 July 2010 regarding whether or not to send the letter. FURTHER RESOLVED, that this motion shall not serve as a precedent requiring the GNSO Council to adhere to a public comment period requirement for any future GNSO Council letters. PROPOSED LETTER: To: Kurt Pritz and members of the ICANN New GTLD Implementation Team, CC: ICANN Board The GNSO Council requests a change to Module 2 of the Draft Applicant Guidebook. Specifically, we request that the section on "Outcomes of the String Similarity Review" be amended to allow applicants to request an Extended Review under applicable terms similar to those provided for other issues such as "DNS Stability: String Review Procedure". We further request that a section be added on ³String Similarity - Extended Review² that parallels other such sections in Module 2. This request is seen as urgent because there are conditions under which it may be appropriate for applicants to request Extended Review for a string which has been denied further processing based on a finding of confusing similarity in the Initial Evaluation. This Extended Review would evaluate extenuating circumstances in the application that may result in a finding of no detrimental confusion notwithstanding the Initial Evaluation. This may occur, inter alia, in cases such as: · The same Registry Operator (for an existing gTLD or a proposed new gTLD) could apply for a string that, although similar to an existing or applied for string, is not detrimentally similar from a user point of view. For example, it is possible that an applicant could apply for both a gTLD with a conventional ASCII label and a corresponding internationalized gTLD (IDN gTLD) that could be found confusingly similar in the Initial Evaluation, but not result in the detrimental user confusion that the GNSO recommendation was trying to avoid. · A situation where there is an agreement between a new applicant Registry Operator and the Registry Operator of an existing gTLD that allows for better service for the users in the geographical area where the new gTLD will be offered. For example, MuseDoma, the Registry Operator for .museum could enter into an agreement with a new gTLD applicant to offer an IDN version of .museum for a specific language community. The two strings might be found confusingly similar in the Initial Evaluation even though the delegation of both would not cause detrimental confusion. We thank you for your prompt attention to this GNSO Council request. The motion passed with a majority of the Contracted Parties House and unanimously in the Non Contracted Parties House by roll call vote. Contracted Parties House : 5 votes in favour 2 Councillors absent, Tim Ruiz, Adrian Kinderis Non Contracted Parties House: 13 votes in favour Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

ccNSO Update - Delegation - Re-Delegation Working Group
by Olga Cavalli June 11, 2010

June 11, 2010

Hi, Attache is a progress report from the Delegation Re-delegation working group together with an Issue Analysis document. Both of these will be formally published on the ICANN web site for comment soon. There will be a session to discuss these documents during the ccNSO members’ meeting in Brussels. Regards Olga

1 0

Motion on AoC; amendment
by KnobenW＠telekom.de June 10, 2010

June 10, 2010

Suggestion for amendment: The 2nd "Resolved" should read: Resolved further, that the GNSO Council should implement the Endorsement Process for all future AOC review team selections, including the "WHOIS Policy" and the "Security, Stability, and Resiliency of the DNS" Review Teams; Regards Wolf-Ulrich

3 3

MP3 recording GNSO Council teleconference, Thursday, 10 June 2010
by Glen de Saint Géry June 10, 2010

June 10, 2010

[To: ga[at]gnso.icann.org; announce[at]gnso.icann.org [To: liaison6c[at]gnso.icann.org; council[at]gnso.icann.org] Please find the MP3 recording of the GNSO Council teleconference, held on Thursday, 10 June, 2010 at: http://audio.icann.org/gnso/gnso-council-20100610.mp3 on page http://gnso.icann.org/calendar/#jun Happy listening! Glen de Saint Géry GNSO Secretariat gnso.secretariat(a)gnso.icann.org http://gnso.icann.org

1 0

Redline of proposed language
by Rosette, Kristina June 10, 2010

June 10, 2010

Here's the redline:

1 0

Language suggestions
by Rosette, Kristina June 10, 2010

June 10, 2010

Too complicated to say what changed where so here's some suggested revised language: This request is seen as urgent because there are conditions under which it may be appropriate for applicants to request Extended Review for a string which has been denied further processing based on a finding of confusing similarity in the Initial Evaluation. This Extended Review would evaluate extenuating circumstances in the application that may result in a finding of no detrimental confusion notwithstanding the Initial Evaluation. This may occur, inter alia, in cases such as: * The same Registry Operator (for an existing gTLD or a proposed new gTLD) could apply for a string that, although similar to an existing or applied for string, is not detrimentally similar from a user point of view. For example, it is possible that an applicant could apply for both a gTLD with a conventional ASCII label and a corresponding internationalized gTLD (IDN gTLD) that could be found confusingly similar in the Initial Evaluation, but no result in the detrimental user confusion that the GNSO recommendation was trying to avoid. * A situation where there is an agreement between a new applicant Registry Operator and the Registry Operator of an existing gTLD that allows for better service for the users in the geographical area where the new gTLD will be offered. For example, MuseDoma, the Registry Operator for .museum could enter into an agreement with a new gTLD applicant to offer an IDN version of .museum for a specific language community. The two strings might be found confusingly similar in the Initial Evaluation even though the delegation of both would not cause detrimental confusion. We thank you for your prompt attention to this GNSO Council request.

2 1