September 2003 - council - lists.icann.org

RE: [council] voting procedures
by Neuman, Jeff 25 Sep '03

25 Sep '03

I have not found any issue that we have dealt with so far that didn't have the flexibility to have at least a few days of review by the constituencies. We should never be making any decisions that do not have such flexibility. Jeff -----Original Message----- From: Philip Sheppard [mailto:philip.sheppard@aim.be] Sent: Thursday, September 25, 2003 11:24 AM To: Council (E-mail) Subject: Re: [council] voting procedures Jeff, you are quite right about consultation. We all want to do this and indeed the old DNSO procedures laid all this out. Nothing should change for normal issues. The other flexibility is when there is a need to make a quick decision. Philip

1 0

RE: [council] voting procedures
by Neuman, Jeff 25 Sep '03

25 Sep '03

I think we agree. There should be time to review the initial resolution as well as time to review the amendments. -----Original Message----- From: Amadeu Abril i Abril [mailto:Amadeu@abril.info] Sent: Thursday, September 25, 2003 11:28 AM To: Neuman, Jeff Cc: Council (E-mail) Subject: Re: [council] voting procedures Neuman, Jeff wrote: > I disagree to the extent that I would like to have time to review > motions on policy with my constituency. Jeff, this does not change my proposal. Even when we have the proposals one week, or one month, before the call, the problem with on-the-fly amendments remain. If a motion is not amendned at all and was on the table before the meeting, no problem with the usual proceudre. But whenever we start to play with its language, I would like to see: * a "visual support" (if you all were using Macs, I'd suggest SubEthaEdit http://www.codingmonkeys.de/subethaedit/) * In case some people cannot access the written version of the amendments, and specifically request so, that the vote be delayed and performed in the immediate 24 hours though email. I'ts not about time for digesting the policies, but the edits... taht sometime affect the substance. Amadeu

1 0

RE: [council] voting procedures
by Neuman, Jeff 25 Sep '03

25 Sep '03

I disagree to the extent that I would like to have time to review motions on policy with my constituency. I believe we all should have the right and opportunity. In fact one of the items I remain a little disconcerted about is that the resolution today was not able to be vetted by the constituencies. Therefore, I would recommend that all resolutions be provided with at least 1 weeks notice prior to a meeting or a vote. Then, we can have a voting period by phone or e-mail. Lets not forget that we represent communities of interest. Thanks. -----Original Message----- From: Philip Sheppard [mailto:philip.sheppard@aim.be] Sent: Thursday, September 25, 2003 11:09 AM To: Council (E-mail) Subject: [council] voting procedures I do agree - an quick e-mail vote process on policy issues would be most useful.

3 2

FW: FW: Revised Resolution regarding Verisign Registry Site Finder Service
by Cade,Marilyn S - LGCRP 25 Sep '03

25 Sep '03

> > > Whereas, on September 15, 2003, VeriSign Registry introduced a wild > card registry service into .com and .net zones that creates a > registry-synthesized address record in response to look ups of domain > names that are not present in the zone. This registry service changes > the routing of traffic by directing traffic that would have otherwise > resulted in a 'no domain' notification to the "sender" to a VeriSign > operated web site with search results and links to paid > advertisements. > Whereas the IAB commentary published its architectural Concerns on the > use of DNS wildcards on 19 September 2003. >Whereas VeriSign Registry on 21 September 2003, responded to Paul > Twomey, President and CEO, ICANN, acknowledging ICANN's advisory and > declining to suspend the service until they (VeriSign) has an > opportunity to collect and review available data. > Whereas the Security and Stability Advisory Committee, 22 September > 2003,has published its recommendations regarding VeriSign's Introduction of Wild Card Response to Uninstantiated Domains within COM and NET on the ICANN web site at www.icann.org > > Therefore, the gNSO Council: > > Supports ICANN's actions to > 1) monitor community reaction and experiences with the new registry > service > 2) request advice from the Security and Stability Advisory Committee > and from the IAB on the impact of change introduced by the registry > service of VeriSign > 3) encourages broad participation by the community in the upcoming > meeting hosted by the Security and Stability Advisory Committee [> > > Pledges to > 1) work cooperatively to ensure full opportunity to fully understand > the service, its implications for the DNS, and any implications for the need for Policy development within the scope of the gNSO.

4 3

Final Resolution regarding Verisign Registry Site Finder Service
by GNSO SECRETARIAT 25 Sep '03

25 Sep '03

[To: council(a)gnso.icann.org] GNSO Council teleconference 25 September 2003. http://gnso.icann.org/meetings/agenda-25sep03.shtml Item 4. Issues associated with Verisign's introduction of wild card entries (*.com and *.net in the .com and .net zonefile) Final Resolution regarding Verisign Registry Site Finder Service proposed by Marilyn Cade and voted on by Council: Whereas, on September 15, 2003, VeriSign Registry introduced a wild card service into .com and .net zones that creates a registry-synthesized address record in response to look ups of domain names that are not present in the zone. This service changes the routing of traffic by directing traffic that would have otherwise resulted in a 'no domain' notification to the "sender" to a VeriSign operated web site with search results and links to paid advertisements. Whereas the IAB commentary published its architectural Concerns on the use of DNS wildcards on 19 September 2003. (LINK) Whereas VeriSign Registry on 21 September 2003, responded to Paul Twomey, President and CEO, ICANN, acknowledging ICANN's advisory and declining to suspend the service until they (VeriSign) has an opportunity to collect and review available data. Whereas the Security and Stability Advisory Committee, 22 September 2003,has published its recommendations at www.icann.org Therefore, the gNSO Council: Supports ICANN's actions to 1) monitor community reaction and experiences with the new service 2) request advice from the Security and Stability Advisory Committee and from the IAB on the impact of change introduced by the registry service of VeriSign 3) encourages broad participation by the community in the upcoming meeting hosted by the Security and Stability Advisory Committee Pledges to 1) Support the recommendation of of the Security and Stability Advisory Committee, 22 September 2003 2) work cooperatively to ensure full opportunity to fully understand the service, its implications for the DNS, and any implications for the need for policy development within the scope of the gNSO. The motion carried, 17 votes in support 6 abstaining votes. GNSO Secretariat

1 0

RE: [council] voting procedures
by Cade,Marilyn S - LGCRP 25 Sep '03

25 Sep '03

Perhaps it is possible to separate votes for elections and votes on policy? 202-255-7348c mcade(a)att.com -----Original Message----- From: Amadeu Abril i Abril [mailto:Amadeu@abril.info] Sent: Thursday, September 25, 2003 10:24 AM Cc: Council (E-mail) Subject: [council] voting procedures Bruce and all, I think that in Carthage we should spend some minutes discussing better ways of managing votes on resolutions. Amending resolutions on the fly over the phone makes understanding the final picture very difficult. Indeed, if we do have net access we always can see modified versions (but we still should be able to find a ways to wathc the amendments being introduced. Unfortunately not everybody can have mail/web access during teleconfs. So we also need to revisit the written procedure for voting. I dont think that we should require a confirmation by subsequent teleconf. Perhaps this is so for the legal Board of a California corporation, but the GNSO is an adivsory policy body, and whould enjoiy more flexibility. Amadeu

1 0

UDRP issues for registrars
by Bruce Tonkin 25 Sep '03

25 Sep '03

Hello All, There has been little response on the issue of UDRP from the registrars constituency. I posted a possible top 5 and only received two responses. It seems that issues: 4, 5, 9, 11 are of some interest. I am sure that registrars will assist in providing advice on implementation details that are the responsibility of registrars, but would generally expect that the intellectual property and users constituencies would drive policy development in this area. Regards, Bruce Tonkin Registrars constituency representative

1 0

Revised Resolution regarding Verisign Registry Site Finder Service
by Cade,Marilyn S - LGCRP 25 Sep '03

25 Sep '03

Dear fellow Councilors and liaisons Given input from some other councilors, other events of relevance, I am submitting a modified version of my earlier resolution to Council. The intent of the resolution is to establish Council's interest and concern; to show the Council's support to Board and President, and to the Security and Stability Advisory Committee for their actions to date, and to indicate the Council's commitment to participate fully in all processes to better understand the impact of new registry level service on the DNS and Internet, and to advise the Board of the intent of Council to undertake any relevant and appropriate work related policy development. -- "Whereas, the primary and overriding imperative to ICANN's mission is the stability and reliability of the global DNS and the Internet. All entities of ICANN share responsibility to consider reliable, predictable, secure, and stable operation of the DNS and the Internet infrastructure in the development of any policies, or any changes in operations or introduction of new services. Whereas, the global Internet is dependent upon standards and design principles and practices that are undertaken and agreed to by the private sector through collegial and bottom up, consensus based processes. Whereas, on September 15, 2003, VeriSign Registry introduced a wild card registry service into .com and .net zones that creates a registry-synthesized address record in response to look ups of domain names that are not present in the zone. This registry service changes the routing of traffic by directing traffic that would have otherwise resulted in a 'no domain' notification to the "sender" to a VeriSign operated web site with search results and links to paid advertisements. Whereas this change creates the appearance that any possible string of letters is a "live" domain, a significant operational change with many implications that are not yet fully understood. The VeriSign server also substantially changes the way email is queued, routed, and responded to in the .com and .net domains; presenting burdens on ISPs and network connectivity providers of all sizes. Whereas applications developed to rely on a RCODE 3 response for a non existing domain have been negatively affected by this change. Whereas work around at the routing and at the DNS level have been deployed by various members of the community to stop the effect of the wildcards. Whereas, concerns have been expressed by many in the community that wildcards in such significant zones negatively affects the stability of the DNS. Whereas complaints have been received about the service and its harmful and burdensome impact on other service providers and including but not limited to: anti-Spam software is being negatively affected. Whereas, there was no notice, comment, nor consultation with affected infrastructure entities by Verisign Registry. Whereas, significant questions of harm to the stability and reliability of the Internet are raised in a variety of technical forums Whereas the IAB commentary published its architectural Concerns on the use of DNS wildcards on 19 September 2003. Whereas VeriSign Registry on 21 September 2003, responded to Paul Twomey, President and CEO, ICANN, acknowledging ICANN's advisory and declining to suspend the service until they (VeriSign) has an opportunity to collect and review available data. Whereas the Security and Stability Advisory Committee, 22 September 2003,has published its recommendations related to the service advising that the stability of the Internet has been considerably weakened through the introduction of ambiguous and inaccurate responses in the DNS, calling on Verisign to voluntarily suspend the service and participate in the various review processes now underway and on ICANN to examine the procedures of change in service, including provisions to protect users from abrupt changes in service. Therefore, the gNSO Council: Supports ICANN's actions to 1) monitor community reaction and experiences with the new registry service 2) request advice from the Security and Stability Advisory Committee and from the IAB on the impact of change introduced by the registry service of VeriSign 3) encourages broad participation by the community in the upcoming meeting hosted by the Security and Stability Advisory Committee 4) pledges its members support for the upcoming meeting Requests that ICANN 1) provide a ruling of whether this service is a registry level service, in violation of existing accreditation agreements and if so, take immediate appropriate steps to end the service until required process is undertaken; 4) in any event, obtain a suspension of the service until the various reviews on the service are completed and presented to ICANN, whether through voluntary or involuntary means Pledges to 1) work cooperatively to ensure full opportunity to fully understand the service, its implications for the DNS, and what steps are needed for retroactively addressing service introduction, and proactively present a recommendation regarding the need for a formal notice and comment process in the introduction of new services at the registry level via undertaking a PDP. *

2 1

RE: [council] Role of council with respect to Agenda Item 4
by Neuman, Jeff 25 Sep '03

25 Sep '03

Bruce, I do agree with much of what you have stated in your e-mail with respect to the GNSO's role. However, I would like to clarify that that the introduction of registry services is not a policy matter within the scope of the GNSO. Such a policy (or even if you believe a lack of policy) is governed by the contracts and not through the GNSO policy process. This is what the parties (ICANN and the registries) negotiated during the contract negotiations in 2001. Although the parties (ICANN and the registries) may agree to change the contracts, the GNSO, even if it has the consensus of every constituency, may not. I would be happy to answer any questions about the contracts, but I would recommend sticking to Bruce's recommendation. Thanks. Jeff -----Original Message----- From: Bruce Tonkin [mailto:Bruce.Tonkin@melbourneit.com.au] Sent: Wednesday, September 24, 2003 8:15 PM To: council(a)gnso.icann.org Subject: [council] Role of council with respect to Agenda Item 4 Hello All, I would just like to remind the Council that GNSO is "responsible for developing and recommending to the ICANN Board substantive policies relating to generic top-level domains" (taken from the ICANN bylaws, Article X, section 1) In discussed agenda item 4, it is not the GNSO's role to make a decision with respect to whether the Verisign service complies with the existing contracts or policy. That is a role for the ICANN staff with advice from the ICANN General Counsel. It is also not the GNSO's role to make decisions with respect to whether it affects the security and stability of the Internet - that is the role of the Security and Stability Advisory Committee. Given advice from the ICANN General Counsel as to whether the issue is covered by the existing contracts, and given the advice from the Security and Stability Advisory Committee, the GNSO should consider whether the issue being discussed in agenda item 4 highlights a "need" for additional policy. The possible areas of additional policy include: - developing a policy for the introduction of new registry services (e.g relating to what circumstance is approval required from ICANN, and what sort of notice periods should be required) - developing a policy around the introduction of wildcard entries to gtlds (note .museum already has a wildcard entry as part of their agreement with ICANN) My recommendation for agenda item 4 is that we keep the discussion focused on the issues for which the GNSO is responsible for, and also consider whether we need to formally support the actions already taken by ICANN and the Security and Stability Committee. I believe in the past we have taken this approach with respect to the ccNSO, where we have supported the creation of a ccNSO and the recent decisions made by ICANN with respect to the ccNSO. If we believe there is a need for new policy, then we should consider formally commencing the policy development process at the next GNSO Council meeting. The GNSO should primarily be focussed on how to avoid problems in the future. Regards, Bruce Tonkin

2 1

RE: [council] Role of council with respect to Agenda Item 4
by Bruce Tonkin 25 Sep '03

25 Sep '03

Hello Jeff, > However, I would like to > clarify that that the introduction of registry services is > not a policy matter within the scope of the GNSO. Such a > policy (or even if you believe a lack of policy) is governed > by the contracts and not through the GNSO policy process. With reference to the GNSO Policy Development Process in Annex A of the ICANN By-laws, any policy process would start with the creation of an issue report. >From Section 2, part e, of Annex A: "A recommendation from the Staff Manager as to whether the Council should initiate the PDP for this issue (the "Staff Recommendation"). Each Staff Recommendation shall include the opinion of the ICANN General Counsel regarding whether the issue proposed to initiate the PDP is properly within the scope of the ICANN policy process and within the scope of the GNSO. In determining whether the issue is properly within the scope of the ICANN policy process, the General Counsel shall examine whether such issue: 1. is within the scope of ICANN's mission statement; 2. is broadly applicable to multiple situations or organizations; 3. is likely to have lasting value or applicability, albeit with the need for occasional updates; 4. will establish a guide or framework for future decision-making; or 5. implicates or affects an existing ICANN policy. " Thus the ICANN General Counsel would provide advice on whether an issue is within the scope of the ICANN policy process. I note from the unsponsored registry agreement: http://www.icann.org/tlds/agreements/unsponsored/registry-agmt-11may01.h tm That there is provision in clause 4 as follows: "During the Term of this Agreement, Registry Operator shall comply, in its provision of Registry Services, on the schedule provided in Subsection 4.5, with 4.1.1. new or revised specifications (including forms of agreement to which Registry Operator is a party) and policies established by ICANN as Consensus Policies in the manner described in Subsection 4.3," [start of personal comment] I also note that while some changes to the registry agreement would need to be made with mutual consent of ICANN and the registry operator, where ICANN is required to provide consent to a change at the request of a registry operator (e.g see clause 3.2 of the registry agreement), that the GNSO could presumably assist ICANN by developing a procedure or criteria that ICANN may use to provide its consent. In that way, if the ICANN Board approves a GNSO recommendation for a procedure, then that Board decision would bind the ICANN staff in complying with the procedure. There would presumably be no contractual changes involved. [end personal comment] In any case these are good questions to ask the ICANN General Counsel either before we commission an issues report, or as part of an issues report. Regards, Bruce Tonkin

1 0