ICANN/GNSO GNSO Email List Archives

[registrars]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [registrars] Motion to adopt Tasting Position Statement

  • To: Registrars Constituency <registrars@xxxxxxxxxxxxxx>
  • Subject: Re: [registrars] Motion to adopt Tasting Position Statement
  • From: "Robert F. Connelly" <BobC@xxxxxxxxxxxxxxx>
  • Date: Tue, 13 Nov 2007 23:39:54 -0800
  • In-reply-to: <20071109143633.4a871ae7d05d2c98d9abb595d392cd69.71c152113d .wbe@email.secureserver.net>
  • List-id: registrars@xxxxxxxxxxxxxx
  • References: <20071109143633.4a871ae7d05d2c98d9abb595d392cd69.71c152113d.wbe@email.secureserver.net>
  • Sender: owner-registrars@xxxxxxxxxxxxxx

At 02:36 PM 11/9/2007 Friday  -0700, Tim Ruiz wrote:

Dear Members:

Tim Ruiz has posted the attached motion at the date and time shown above.

The following three endorsements have been received:

At 01:13 PM 11/9/2007 Friday  -0800, Robert F. Connelly 
At 10:01 AM 11/12/2007 Monday  +0100, Thomas Keller 
At 11:08 PM 11/12/2007 Monday  +1100, Adrian Kinderis

Adrian's endorsement converts to Noon UTC 11/12/2007.

I now call for the discussion of the motion for14 days starting 11/12/2007 (see I.3, below, not greater than 48 hours).  Here is the voting schedule as specified by the Rules of Procedure:

I.1. The proponent of a motion shall submit it to the Constituency mailing list. Such motion generally would include: a. a substantive description of a new or changed policy, amendment to the Registrar Constituency Bylaws, these Rules, or other policy documents; or b. a position of support for or opposition to a report, policy, or any other matter before the Elected Members of the Constituency. 

I.2. The motion must have three endorsements in order to proceed to formal discussion. Solicitation of endorsements in support of the motion may be secured via the Registrar Constituency mailing list. 

I.3. The Constituency Secretary will publish the motion and call for discussion no later than 48 hours after receiving the motion from the proponent and the three endorsements. 

I.4. Discussion of the motion will be held open on the Constituency list for no less than 14 days. The Chair will moderate the discussion on the list or at any meeting or call, as applicable. 

I.5. During such time, amendments may be put forward by electronic communication to the Secretary. The Secretary will accept and publish any amendment formally to the Constituency list for the Constituency?s consideration only if such amendment is endorsed by a second Member, and such endorsement is communicated by electronic communication to the Secretary and to the Constituency list. 

I.6. During this period of consideration, the proponent of the motion may accept one or all of the amendments as friendly, and modify her or his motion accordingly. Any friendly amendments will be withdrawn and not considered separately. 

I.7. Any Member can call for a vote after the 14-day period post-publication. 

I.8. The Secretary will create and publish the ballot. The ballot will remain open for inspection and possible amendment or correction for 72 hours prior to the vote. 

I.9. The ballot will allow for a vote on each of: 

a. the original motion; and b. any unfriendly amendments (as deemed by the proponent). 

I.10. The Secretary will call the vote no less than 2 days after the end of the ballot inspection period and keep it open for no less than 7 days, but no more than 21 days. In exceptional circumstances as determined by a majority vote of the Constituency Executive Committee, however, the Secretary may shorten or extend the period to vote upon proper notice to the voting members via the constituency mailing list or other similar means. Other than as stated in Section II below, in no event will a vote be open less than 3 business days or longer than 30 days. 

"Publishing" until now has been interpreted as Emailing on the public list hosted by ICANN.

The motion reads as follows:

>I move that we accept the following as the RC position statement and
>submit it to the GNSO Council as such:
>
>The Registrars Constituency (RC) has not reached Supermajority 
>support for a particular position on Domain Name Tasting. Below 
>are statements of the views/positions espoused by RC members. 
>
>View 1. Many registrars believe that Tasting should be curbed if not 
>eliminated altogether for one or more of the following reasons:
>
>a. Tasting is causing general confusion among registrants and 
>potential registrants trying to register domain names.
>
>b. Tasting is eroding consumer confidence in the security and 
>trustworthiness of domain name registration services and our 
>industry in general.
>
>c. Tasting is causing an increase in support costs for Registrars.
>
>d. Tasting violates well-established codes of conduct and good 
>practice intended to ensure security and stability by:
>
>i. disturbing the stability of a set of existing services that 
>had been functioning satisfactorily, namely the competitive 
>domain name registration services developed by Registrars;
>
>ii. disturbing other existing systems and value added services, 
>for example those relying on Zone files, and various third party 
>WHOIS services;
>
>iii. increasing costs that must be absorbed by others not 
>participating in or benefiting from Tasting.
>
>e. Despite the long held tenet of "First do no harm," there has 
>been no research, testing for potential disruption of existing 
>services, public review, or comment prior to this high volume 
>activity abruptly occurring in the DNS.
>
>In summary, high volume Tasting activity has undermined expectations 
>about reliable behavior and in so doing has reduced trust in the 
>security and stability of the system and has increased costs for 
>registrars, registrants, and others not participating in the 
>activity.
>
>View 2. Many registrars believe that Tasting should not be a matter 
>of concern or action by the GNSO or ICANN for one or more of the 
>following reasons:
>
>a. Tasting takes place due to market demand, and the market 
>should be allowed to evolve as demand dictates.
>
>b. ICANN is not a regulatory body, and according to its own 
>bylaws, coordinates policy development reasonably and 
>appropriately related to technical functions of the DNS. ICANN 
>should not be regulating market activity.
>
>Notwithstanding the above, the RC is in near unanimous agreement that 
>sun-setting the Add Grace Period (AGP) is not an appropriate action 
>should the GNSO decide to address Tasting activity. Many Registrars 
>who do not participate in Tasting use the AGP in various ways not 
>related to Tasting, as detailed in section 4.4 of the Outcomes Report 
>of the GNSO Ad Hoc Group on Domain Name Tasting. Report found here:
>
>http://gnso.icann.org/drafts/gnso-domain-tasting-adhoc-outcomes-report-final.pdf
>
>Sun-setting the AGP would unnecessarily put additional burdens and 
>costs on Registrars and Registrants using the AGP for these 
>non-Tasting reasons.
>
>To the extent that the GNSO should decide to recommend policy or 
>actions with the intent of curbing or eliminating Tasting activity, 
>RC members are in general agreement that:
>
>Preferred - The GNSO should recommend that ICANN make the 
>transactional fee component of the variable Registrar fees apply to 
>all new registrations except for a reasonable number that are deleted 
>within the AGP. Implementation time for Registrars would be negligible.
>
>Acceptable but not preferred - The GNSO should encourage gTLD 
>Registries to only allow AGP refunds on a reasonable number of new 
>registrations, noting that such action is affective only if all gTLD 
>registries apply it, and do so in a reasonably consistent manner. 
>Implementation time for Registrars could be substantial depending on 
>how each Registry decided to define their policy. If Registrars need to 
>modify their systems and/or services a minimum of 90-days advance 
>notice should be given.
>
>Note that neither of the above actions requires new policy or 
>modifications to existing policy. Therefore the RC, regardless of their 
>view, is generally opposed to a PDP on this issue.





<<< Chronological Index >>>    <<< Thread Index >>>