Dear All: In follow up to my earlier comments and in response to some of the subsequent discussion by the Council, I thought it might be helpful to clarify the options available to ICANN in modifying registrar obligations under the Registrar Accreditation Agreement (RAA). My earlier comments indicated that two paths were considered to incorporate amendments into the RAA. There are, of course, three ways by which registrar obligations under the RAA can be modified: The first option, which is described in the RAA, requires a report, approval by a two-thirds majority of the GNSO, and ICANN Board action. As indicated previously, a new form of RAA adopted based on a two-thirds¹ vote of the Council would take effect upon expiration of each registrar¹s five-year RAA. With over 70% of all registrars' RAAs expiring between 1 June 2009 and 31 May 2011, the result would have been substantial (compulsory) adoption of the new RAA and significantly improved availability of compliance enforcement tools for most registrars. The proposed amendments did not receive the requisite two-thirds vote for approval. Staff will continue to engage the GNSO membership to address outstanding concerns raised in the process, to determine whether RAA amendment through this path may still be viable. The second option for amending the RAA requires Board approval and the voluntary adoption of a revised RAA by registrars. It is anticipated that some forms of incentive would be required to encourage adoption as I previously described. The third option is the GNSO policy development process that has the ability to modify the terms under which ICANN-accredited registrars do business through the policy development process. In particular, the RAA (at section 4.2: http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.2) allows for the establishment and revision of policies and specifications in the following areas: 4.2.1 issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability, and/or operational stability of Registrar Services, Registry Services, the DNS, or the Internet; 4.2.2 registrar policies reasonably necessary to implement ICANN policies or specifications relating to a DNS registry or to Registry Services; 4.2.3 resolution of disputes concerning the registration of Registered Names (as opposed to the use of such domain names), including where the policies take into account use of the domain names; 4.2.4 principles for allocation of Registered Names (e.g., first-come/first-served, timely renewal, holding period after expiration); 4.2.5 prohibitions on warehousing of or speculation in domain names by registries or registrars; 4.2.6 maintenance of and access to accurate and up-to-date contact information regarding Registered Names and nameservers; 4.2.7 reservation of Registered Names that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of users, (b) intellectual property, or (c) the technical management of the DNS or the Internet (e.g., "example.com" and names with single-letter/digit labels); 4.2.8 procedures to avoid disruptions of registration due to suspension or termination of operations by a registry operator or a registrar, including allocation of responsibility among continuing registrars of the Registered Names sponsored in a TLD by a registrar losing accreditation; and 4.2.9 the transfer of registration data upon a change in registrar sponsoring one or more Registered Names. These topics mark the boundaries of the "picket fence" within which policy development under the current RAA is possible. (A two-thirds GNSO majority would still be required in order for such policies to be enforceable against registrars, as is the case with the RAA amendment process.) The current set of proposed amendments, reached through community consultation and negotiation with registrars, would reach several areas that are not ordinarily subject to policy development within the picket fence. Please keep in mind that we are not evaluating the specific amendments, just the realm of potential policy development, and also that our analysis may not have taken all factors into account. In other words, the determination of what's inside the picket fence could conceivably result in a different answer under different circumstances. The following topics that were included in the original package of amendments sent to the GNSO do appear to fall within the picket fence of potential new obligations that could be imposed on registrars via Consensus Policies: · Escrow of Whois Privacy/Proxy Customer Data · Registrant Rights and Responsibilities Document · Registrar Contractual Relationships with Resellers (where the substantive topic lies within the picket fence) · Disclosure of Registration Licensee Contact Information · Registrar Disclosure of Its Own Contact Information · Operator Skills Training & Testing · Modification of Data Retention Requirements Based on our initial review, the following topics that were included in the original package of amendments sent to the GNSO appear to fall outside the picket fence, and therefore could not be imposed on registrars via Consensus Policies: · Registrar Auditing · Graduated Sanctions & Accreditation Suspension · Registrar Group Liability · Registrar Fees · Registrations by Registrars (the picket fence allows for policy development related to warehousing of domains by registrars, but the topic addressed by the proposed amendment - requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar for registrar business use - would not be enforceable as a Consensus Policy under the RAA) · Modification of Arbitration Rights · Accreditation by Purchase · Use of ICANN-Accredited Registrars (is a topic appropriate for policy development by the GNSO, but it would not be enforceable through the RAA as a "Consensus Policy") · Streamlined Requirements for Registrar Notification of New and Revised Consensus Policies · Removal of References to U.S. Department of Commerce It is our expectation that the GNSO will continue to evaluate the need for and undertake policy development within the picket fence that would be applicable to all registrars. Nevertheless, we still see strong value to registrants and the greater Internet community in the proposed amendments, even if they cannot be uniformly applied at this time. In the event a system of incentives is implemented to encourage voluntary adoption by registrars, we will, of course, consult with the GNSO and its member-constituencies as we have throughout this process, to solicit input with regard to the most beneficial and meaningful ways and tools to encourage registrar cooperation. I hope this information is helpful and clear. I will answer what questions I can and get answers to others. Regards, Kurt Kurt Pritz ICANN 4676 Admiralty Way, Ste. 330 Marina del Rey, CA 90292 +1-310-301-5809 (office) +1-310-400-4184 (mobile)
Thanks Kurt. You are interpreting the RAA in a very narrow and unprecedented way, as Section 4.2 simply says "policies may be established on the following topics..." It does not preclude policy on any other topic. Has ICANN Counsel created this interpretation, or is it simply yours? Moreover, are these your personal opinions as to what falls within and outside the 'picket fence' that you have now attempted to create? Are they ICANN Counsel's opinions? Who is it ultimately that would make those determinations (if we accepted for the moment that such determinations must be made)? Surely the GNSO Council's collective opinion on any such determination ought to be at least as important as ICANN Staff's, and very well might differ. In particular, it appears illogical to say that the Council can develop policy on substantive issues, but cannot develop policy to enforce the resulting rules (via notifications to registrars, auditing, sanctions/suspension, etc.). Also I do not comprehend your attempted distinction between 'policy relating to warehousing' and policy 'requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar'. Regardless of these concerns, I hope the Council will approve the path forward that I have suggested, so that we can reach consensus as to a package of amendments that can be implemented on a compulsory basis as soon as possible. That motion is on the table for Mexico City, so hopefully Staff will give us its views on that motion as soon as possible, as well as further responses to my specific questions above. Thanks, Mike -----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Kurt Pritz Sent: Wednesday, February 18, 2009 11:39 AM To: Council GNSO Subject: [council] RAA Amendments Dear All: In follow up to my earlier comments and in response to some of the subsequent discussion by the Council, I thought it might be helpful to clarify the options available to ICANN in modifying registrar obligations under the Registrar Accreditation Agreement (RAA). My earlier comments indicated that two paths were considered to incorporate amendments into the RAA. There are, of course, three ways by which registrar obligations under the RAA can be modified: The first option, which is described in the RAA, requires a report, approval by a two-thirds majority of the GNSO, and ICANN Board action. As indicated previously, a new form of RAA adopted based on a two-thirds¹ vote of the Council would take effect upon expiration of each registrar¹s five-year RAA. With over 70% of all registrars' RAAs expiring between 1 June 2009 and 31 May 2011, the result would have been substantial (compulsory) adoption of the new RAA and significantly improved availability of compliance enforcement tools for most registrars. The proposed amendments did not receive the requisite two-thirds vote for approval. Staff will continue to engage the GNSO membership to address outstanding concerns raised in the process, to determine whether RAA amendment through this path may still be viable. The second option for amending the RAA requires Board approval and the voluntary adoption of a revised RAA by registrars. It is anticipated that some forms of incentive would be required to encourage adoption as I previously described. The third option is the GNSO policy development process that has the ability to modify the terms under which ICANN-accredited registrars do business through the policy development process. In particular, the RAA (at section 4.2: http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.2) allows for the establishment and revision of policies and specifications in the following areas: 4.2.1 issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability, and/or operational stability of Registrar Services, Registry Services, the DNS, or the Internet; 4.2.2 registrar policies reasonably necessary to implement ICANN policies or specifications relating to a DNS registry or to Registry Services; 4.2.3 resolution of disputes concerning the registration of Registered Names (as opposed to the use of such domain names), including where the policies take into account use of the domain names; 4.2.4 principles for allocation of Registered Names (e.g., first-come/first-served, timely renewal, holding period after expiration); 4.2.5 prohibitions on warehousing of or speculation in domain names by registries or registrars; 4.2.6 maintenance of and access to accurate and up-to-date contact information regarding Registered Names and nameservers; 4.2.7 reservation of Registered Names that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of users, (b) intellectual property, or (c) the technical management of the DNS or the Internet (e.g., "example.com" and names with single-letter/digit labels); 4.2.8 procedures to avoid disruptions of registration due to suspension or termination of operations by a registry operator or a registrar, including allocation of responsibility among continuing registrars of the Registered Names sponsored in a TLD by a registrar losing accreditation; and 4.2.9 the transfer of registration data upon a change in registrar sponsoring one or more Registered Names. These topics mark the boundaries of the "picket fence" within which policy development under the current RAA is possible. (A two-thirds GNSO majority would still be required in order for such policies to be enforceable against registrars, as is the case with the RAA amendment process.) The current set of proposed amendments, reached through community consultation and negotiation with registrars, would reach several areas that are not ordinarily subject to policy development within the picket fence. Please keep in mind that we are not evaluating the specific amendments, just the realm of potential policy development, and also that our analysis may not have taken all factors into account. In other words, the determination of what's inside the picket fence could conceivably result in a different answer under different circumstances. The following topics that were included in the original package of amendments sent to the GNSO do appear to fall within the picket fence of potential new obligations that could be imposed on registrars via Consensus Policies: · Escrow of Whois Privacy/Proxy Customer Data · Registrant Rights and Responsibilities Document · Registrar Contractual Relationships with Resellers (where the substantive topic lies within the picket fence) · Disclosure of Registration Licensee Contact Information · Registrar Disclosure of Its Own Contact Information · Operator Skills Training & Testing · Modification of Data Retention Requirements Based on our initial review, the following topics that were included in the original package of amendments sent to the GNSO appear to fall outside the picket fence, and therefore could not be imposed on registrars via Consensus Policies: · Registrar Auditing · Graduated Sanctions & Accreditation Suspension · Registrar Group Liability · Registrar Fees · Registrations by Registrars (the picket fence allows for policy development related to warehousing of domains by registrars, but the topic addressed by the proposed amendment - requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar for registrar business use - would not be enforceable as a Consensus Policy under the RAA) · Modification of Arbitration Rights · Accreditation by Purchase · Use of ICANN-Accredited Registrars (is a topic appropriate for policy development by the GNSO, but it would not be enforceable through the RAA as a "Consensus Policy") · Streamlined Requirements for Registrar Notification of New and Revised Consensus Policies · Removal of References to U.S. Department of Commerce It is our expectation that the GNSO will continue to evaluate the need for and undertake policy development within the picket fence that would be applicable to all registrars. Nevertheless, we still see strong value to registrants and the greater Internet community in the proposed amendments, even if they cannot be uniformly applied at this time. In the event a system of incentives is implemented to encourage voluntary adoption by registrars, we will, of course, consult with the GNSO and its member-constituencies as we have throughout this process, to solicit input with regard to the most beneficial and meaningful ways and tools to encourage registrar cooperation. I hope this information is helpful and clear. I will answer what questions I can and get answers to others. Regards, Kurt Kurt Pritz ICANN 4676 Admiralty Way, Ste. 330 Marina del Rey, CA 90292 +1-310-301-5809 (office) +1-310-400-4184 (mobile)
Mike, We obviously disagree with your expansive interpretation of the RAA, and would welcome guidance from the General Counsel on this issue. Per your motion, would you have the Council formulate and seek to approve amendments to the RAA that are not supported by both of the parties to the contract? In other words, is the intent of your motion to provide guidance to the parties or to have Council move forward and approve changes that it thinks is best? Thanks. Stéphane Van Gelder Le 19/02/09 00:34, « Mike Rodenbaugh » <icann@rodenbaugh.com> a écrit :
Thanks Kurt. You are interpreting the RAA in a very narrow and unprecedented way, as Section 4.2 simply says "policies may be established on the following topics..." It does not preclude policy on any other topic. Has ICANN Counsel created this interpretation, or is it simply yours?
Moreover, are these your personal opinions as to what falls within and outside the 'picket fence' that you have now attempted to create? Are they ICANN Counsel's opinions? Who is it ultimately that would make those determinations (if we accepted for the moment that such determinations must be made)? Surely the GNSO Council's collective opinion on any such determination ought to be at least as important as ICANN Staff's, and very well might differ.
In particular, it appears illogical to say that the Council can develop policy on substantive issues, but cannot develop policy to enforce the resulting rules (via notifications to registrars, auditing, sanctions/suspension, etc.).
Also I do not comprehend your attempted distinction between 'policy relating to warehousing' and policy 'requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar'.
Regardless of these concerns, I hope the Council will approve the path forward that I have suggested, so that we can reach consensus as to a package of amendments that can be implemented on a compulsory basis as soon as possible. That motion is on the table for Mexico City, so hopefully Staff will give us its views on that motion as soon as possible, as well as further responses to my specific questions above.
Thanks, Mike
-----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Kurt Pritz Sent: Wednesday, February 18, 2009 11:39 AM To: Council GNSO Subject: [council] RAA Amendments
Dear All:
In follow up to my earlier comments and in response to some of the subsequent discussion by the Council, I thought it might be helpful to clarify the options available to ICANN in modifying registrar obligations under the Registrar Accreditation Agreement (RAA). My earlier comments indicated that two paths were considered to incorporate amendments into the RAA.
There are, of course, three ways by which registrar obligations under the RAA can be modified:
The first option, which is described in the RAA, requires a report, approval by a two-thirds majority of the GNSO, and ICANN Board action. As indicated previously, a new form of RAA adopted based on a two-thirds¹ vote of the Council would take effect upon expiration of each registrar¹s five-year RAA. With over 70% of all registrars' RAAs expiring between 1 June 2009 and 31 May 2011, the result would have been substantial (compulsory) adoption of the new RAA and significantly improved availability of compliance enforcement tools for most registrars. The proposed amendments did not receive the requisite two-thirds vote for approval. Staff will continue to engage the GNSO membership to address outstanding concerns raised in the process, to determine whether RAA amendment through this path may still be viable.
The second option for amending the RAA requires Board approval and the voluntary adoption of a revised RAA by registrars. It is anticipated that some forms of incentive would be required to encourage adoption as I previously described.
The third option is the GNSO policy development process that has the ability to modify the terms under which ICANN-accredited registrars do business through the policy development process. In particular, the RAA (at section 4.2: http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.2) allows for the establishment and revision of policies and specifications in the following areas:
4.2.1 issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability, and/or operational stability of Registrar Services, Registry Services, the DNS, or the Internet;
4.2.2 registrar policies reasonably necessary to implement ICANN policies or specifications relating to a DNS registry or to Registry Services;
4.2.3 resolution of disputes concerning the registration of Registered Names (as opposed to the use of such domain names), including where the policies take into account use of the domain names;
4.2.4 principles for allocation of Registered Names (e.g., first-come/first-served, timely renewal, holding period after expiration);
4.2.5 prohibitions on warehousing of or speculation in domain names by registries or registrars;
4.2.6 maintenance of and access to accurate and up-to-date contact information regarding Registered Names and nameservers;
4.2.7 reservation of Registered Names that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of users, (b) intellectual property, or (c) the technical management of the DNS or the Internet (e.g., "example.com" and names with single-letter/digit labels);
4.2.8 procedures to avoid disruptions of registration due to suspension or termination of operations by a registry operator or a registrar, including allocation of responsibility among continuing registrars of the Registered Names sponsored in a TLD by a registrar losing accreditation; and
4.2.9 the transfer of registration data upon a change in registrar sponsoring one or more Registered Names.
These topics mark the boundaries of the "picket fence" within which policy development under the current RAA is possible. (A two-thirds GNSO majority would still be required in order for such policies to be enforceable against registrars, as is the case with the RAA amendment process.)
The current set of proposed amendments, reached through community consultation and negotiation with registrars, would reach several areas that are not ordinarily subject to policy development within the picket fence. Please keep in mind that we are not evaluating the specific amendments, just the realm of potential policy development, and also that our analysis may not have taken all factors into account. In other words, the determination of what's inside the picket fence could conceivably result in a different answer under different circumstances.
The following topics that were included in the original package of amendments sent to the GNSO do appear to fall within the picket fence of potential new obligations that could be imposed on registrars via Consensus Policies:
· Escrow of Whois Privacy/Proxy Customer Data
· Registrant Rights and Responsibilities Document
· Registrar Contractual Relationships with Resellers (where the substantive topic lies within the picket fence)
· Disclosure of Registration Licensee Contact Information
· Registrar Disclosure of Its Own Contact Information
· Operator Skills Training & Testing
· Modification of Data Retention Requirements
Based on our initial review, the following topics that were included in the original package of amendments sent to the GNSO appear to fall outside the picket fence, and therefore could not be imposed on registrars via Consensus Policies:
· Registrar Auditing
· Graduated Sanctions & Accreditation Suspension
· Registrar Group Liability
· Registrar Fees
· Registrations by Registrars (the picket fence allows for policy development related to warehousing of domains by registrars, but the topic addressed by the proposed amendment - requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar for registrar business use - would not be enforceable as a Consensus Policy under the RAA)
· Modification of Arbitration Rights
· Accreditation by Purchase
· Use of ICANN-Accredited Registrars (is a topic appropriate for policy development by the GNSO, but it would not be enforceable through the RAA as a "Consensus Policy")
· Streamlined Requirements for Registrar Notification of New and Revised Consensus Policies
· Removal of References to U.S. Department of Commerce
It is our expectation that the GNSO will continue to evaluate the need for and undertake policy development within the picket fence that would be applicable to all registrars. Nevertheless, we still see strong value to registrants and the greater Internet community in the proposed amendments, even if they cannot be uniformly applied at this time. In the event a system of incentives is implemented to encourage voluntary adoption by registrars, we will, of course, consult with the GNSO and its member-constituencies as we have throughout this process, to solicit input with regard to the most beneficial and meaningful ways and tools to encourage registrar cooperation.
I hope this information is helpful and clear. I will answer what questions I can and get answers to others.
Regards,
Kurt
Kurt Pritz ICANN
4676 Admiralty Way, Ste. 330 Marina del Rey, CA 90292
+1-310-301-5809 (office) +1-310-400-4184 (mobile)
Stephane, I agree we should get ICANN Counsel's interpretation as a logical next step in this debate. The intent of my motion is to have Council agree on a subset of the amendments agreed between ICANN Staff and the Registrars Constituency, and forward that recommendation to the Board for compulsory implementation. Then, the Council would provide guidance as to additional and/or different amendments that the community would like to see made to the RAA, and forward that recommendation to the Board as well. Thanks, Mike -----Original Message----- From: Stéphane Van Gelder [mailto:stephane.vangelder@indom.com] Sent: Thursday, February 19, 2009 7:43 AM To: icann@rodenbaugh.com; Kurt Pritz; council@gnso.icann.org Subject: Re: [council] RAA Amendments Mike, We obviously disagree with your expansive interpretation of the RAA, and would welcome guidance from the General Counsel on this issue. Per your motion, would you have the Council formulate and seek to approve amendments to the RAA that are not supported by both of the parties to the contract? In other words, is the intent of your motion to provide guidance to the parties or to have Council move forward and approve changes that it thinks is best? Thanks. Stéphane Van Gelder Le 19/02/09 00:34, « Mike Rodenbaugh » <icann@rodenbaugh.com> a écrit :
Thanks Kurt. You are interpreting the RAA in a very narrow and unprecedented way, as Section 4.2 simply says "policies may be established on the following topics..." It does not preclude policy on any other
topic.
Has ICANN Counsel created this interpretation, or is it simply yours?
Moreover, are these your personal opinions as to what falls within and outside the 'picket fence' that you have now attempted to create? Are they ICANN Counsel's opinions? Who is it ultimately that would make those determinations (if we accepted for the moment that such determinations must be made)? Surely the GNSO Council's collective opinion on any such determination ought to be at least as important as ICANN Staff's, and very well might differ.
In particular, it appears illogical to say that the Council can develop policy on substantive issues, but cannot develop policy to enforce the resulting rules (via notifications to registrars, auditing, sanctions/suspension, etc.).
Also I do not comprehend your attempted distinction between 'policy relating to warehousing' and policy 'requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar'.
Regardless of these concerns, I hope the Council will approve the path forward that I have suggested, so that we can reach consensus as to a package of amendments that can be implemented on a compulsory basis as soon as possible. That motion is on the table for Mexico City, so hopefully Staff will give us its views on that motion as soon as possible, as well as further responses to my specific questions above.
Thanks, Mike
-----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Kurt Pritz Sent: Wednesday, February 18, 2009 11:39 AM To: Council GNSO Subject: [council] RAA Amendments
Dear All:
In follow up to my earlier comments and in response to some of the subsequent discussion by the Council, I thought it might be helpful to clarify the options available to ICANN in modifying registrar obligations under the Registrar Accreditation Agreement (RAA). My earlier comments indicated that two paths were considered to incorporate amendments into the RAA.
There are, of course, three ways by which registrar obligations under the RAA can be modified:
The first option, which is described in the RAA, requires a report, approval by a two-thirds majority of the GNSO, and ICANN Board action. As indicated previously, a new form of RAA adopted based on a two-thirds¹ vote of the Council would take effect upon expiration of each registrar¹s five-year RAA. With over 70% of all registrars' RAAs expiring between 1 June 2009 and 31 May 2011, the result would have been substantial (compulsory) adoption of the new RAA and significantly improved availability of compliance enforcement tools for most registrars. The proposed amendments did not receive the requisite two-thirds vote for approval. Staff will continue to engage the GNSO membership to address outstanding concerns raised in the process, to determine whether RAA amendment through this path may still be viable.
The second option for amending the RAA requires Board approval and the voluntary adoption of a revised RAA by registrars. It is anticipated that some forms of incentive would be required to encourage adoption as I previously described.
The third option is the GNSO policy development process that has the ability to modify the terms under which ICANN-accredited registrars do business through the policy development process. In particular, the RAA (at section 4.2: http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.2) allows for the establishment and revision of policies and specifications in the following areas:
4.2.1 issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability, and/or operational stability of Registrar Services, Registry Services, the DNS, or the Internet;
4.2.2 registrar policies reasonably necessary to implement ICANN policies or specifications relating to a DNS registry or to Registry Services;
4.2.3 resolution of disputes concerning the registration of Registered Names (as opposed to the use of such domain names), including where the policies take into account use of the domain names;
4.2.4 principles for allocation of Registered Names (e.g., first-come/first-served, timely renewal, holding period after expiration);
4.2.5 prohibitions on warehousing of or speculation in domain names by registries or registrars;
4.2.6 maintenance of and access to accurate and up-to-date contact information regarding Registered Names and nameservers;
4.2.7 reservation of Registered Names that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of users, (b) intellectual property, or (c) the technical management of the DNS or the Internet (e.g., "example.com" and names with single-letter/digit labels);
4.2.8 procedures to avoid disruptions of registration due to suspension or termination of operations by a registry operator or a registrar, including allocation of responsibility among continuing registrars of the Registered Names sponsored in a TLD by a registrar losing accreditation; and
4.2.9 the transfer of registration data upon a change in registrar sponsoring one or more Registered Names.
These topics mark the boundaries of the "picket fence" within which policy development under the current RAA is possible. (A two-thirds GNSO majority would still be required in order for such policies to be enforceable against registrars, as is the case with the RAA amendment process.)
The current set of proposed amendments, reached through community consultation and negotiation with registrars, would reach several areas that are not ordinarily subject to policy development within the picket fence. Please keep in mind that we are not evaluating the specific amendments, just the realm of potential policy development, and also that our analysis may not have taken all factors into account. In other words, the determination of what's inside the picket fence could conceivably result in a different answer under different circumstances.
The following topics that were included in the original package of amendments sent to the GNSO do appear to fall within the picket fence of potential new obligations that could be imposed on registrars via Consensus Policies:
· Escrow of Whois Privacy/Proxy Customer Data
· Registrant Rights and Responsibilities Document
· Registrar Contractual Relationships with Resellers (where the substantive topic lies within the picket fence)
· Disclosure of Registration Licensee Contact Information
· Registrar Disclosure of Its Own Contact Information
· Operator Skills Training & Testing
· Modification of Data Retention Requirements
Based on our initial review, the following topics that were included in the original package of amendments sent to the GNSO appear to fall outside the picket fence, and therefore could not be imposed on registrars via Consensus Policies:
· Registrar Auditing
· Graduated Sanctions & Accreditation Suspension
· Registrar Group Liability
· Registrar Fees
· Registrations by Registrars (the picket fence allows for policy development related to warehousing of domains by registrars, but the topic addressed by the proposed amendment - requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar for registrar business use - would not be enforceable as a Consensus Policy under the RAA)
· Modification of Arbitration Rights
· Accreditation by Purchase
· Use of ICANN-Accredited Registrars (is a topic appropriate for policy development by the GNSO, but it would not be enforceable through the RAA as a "Consensus Policy")
· Streamlined Requirements for Registrar Notification of New and Revised Consensus Policies
· Removal of References to U.S. Department of Commerce
It is our expectation that the GNSO will continue to evaluate the need for and undertake policy development within the picket fence that would be applicable to all registrars. Nevertheless, we still see strong value to registrants and the greater Internet community in the proposed amendments, even if they cannot be uniformly applied at this time. In the event a system of incentives is implemented to encourage voluntary adoption by registrars, we will, of course, consult with the GNSO and its member-constituencies as we have throughout this process, to solicit input with regard to the most beneficial and meaningful ways and tools to encourage registrar cooperation.
I hope this information is helpful and clear. I will answer what questions I can and get answers to others.
Regards,
Kurt
Kurt Pritz ICANN
4676 Admiralty Way, Ste. 330 Marina del Rey, CA 90292
+1-310-301-5809 (office) +1-310-400-4184 (mobile)
Mike, Thanks for clarifying. Under the ICANN Bylaws, the GNSO is a policy-making body and not a body to be drafting contract language to be sent to the Board in an attempt to bind a party to provisions without their consent - especially provisions outside of those enumerated in the contract as the potential subject matter of policies (the picket fence). This appears to be nothing more than a land grab, which is outside the scope of the GNSO. If you want to bind registrars to a new policy on something within the picket fence, go through the PDP process. You appear to be trying to do an end run around the PDP process and the picket fence, however, in violation of ICANN's Bylaws and contracts, and your attempt should be unacceptable to the Council. Stéphane Le 19/02/09 17:47, « Mike Rodenbaugh » <icann@rodenbaugh.com> a écrit :
Stephane,
I agree we should get ICANN Counsel's interpretation as a logical next step in this debate.
The intent of my motion is to have Council agree on a subset of the amendments agreed between ICANN Staff and the Registrars Constituency, and forward that recommendation to the Board for compulsory implementation. Then, the Council would provide guidance as to additional and/or different amendments that the community would like to see made to the RAA, and forward that recommendation to the Board as well.
Thanks, Mike
-----Original Message----- From: Stéphane Van Gelder [mailto:stephane.vangelder@indom.com] Sent: Thursday, February 19, 2009 7:43 AM To: icann@rodenbaugh.com; Kurt Pritz; council@gnso.icann.org Subject: Re: [council] RAA Amendments
Mike,
We obviously disagree with your expansive interpretation of the RAA, and would welcome guidance from the General Counsel on this issue.
Per your motion, would you have the Council formulate and seek to approve amendments to the RAA that are not supported by both of the parties to the contract? In other words, is the intent of your motion to provide guidance to the parties or to have Council move forward and approve changes that it thinks is best?
Thanks.
Stéphane Van Gelder
Le 19/02/09 00:34, « Mike Rodenbaugh » <icann@rodenbaugh.com> a écrit :
Thanks Kurt. You are interpreting the RAA in a very narrow and unprecedented way, as Section 4.2 simply says "policies may be established on the following topics..." It does not preclude policy on any other
topic.
Has ICANN Counsel created this interpretation, or is it simply yours?
Moreover, are these your personal opinions as to what falls within and outside the 'picket fence' that you have now attempted to create? Are they ICANN Counsel's opinions? Who is it ultimately that would make those determinations (if we accepted for the moment that such determinations must be made)? Surely the GNSO Council's collective opinion on any such determination ought to be at least as important as ICANN Staff's, and very well might differ.
In particular, it appears illogical to say that the Council can develop policy on substantive issues, but cannot develop policy to enforce the resulting rules (via notifications to registrars, auditing, sanctions/suspension, etc.).
Also I do not comprehend your attempted distinction between 'policy relating to warehousing' and policy 'requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar'.
Regardless of these concerns, I hope the Council will approve the path forward that I have suggested, so that we can reach consensus as to a package of amendments that can be implemented on a compulsory basis as soon as possible. That motion is on the table for Mexico City, so hopefully Staff will give us its views on that motion as soon as possible, as well as further responses to my specific questions above.
Thanks, Mike
-----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Kurt Pritz Sent: Wednesday, February 18, 2009 11:39 AM To: Council GNSO Subject: [council] RAA Amendments
Dear All:
In follow up to my earlier comments and in response to some of the subsequent discussion by the Council, I thought it might be helpful to clarify the options available to ICANN in modifying registrar obligations under the Registrar Accreditation Agreement (RAA). My earlier comments indicated that two paths were considered to incorporate amendments into the RAA.
There are, of course, three ways by which registrar obligations under the RAA can be modified:
The first option, which is described in the RAA, requires a report, approval by a two-thirds majority of the GNSO, and ICANN Board action. As indicated previously, a new form of RAA adopted based on a two-thirds¹ vote of the Council would take effect upon expiration of each registrar¹s five-year RAA. With over 70% of all registrars' RAAs expiring between 1 June 2009 and 31 May 2011, the result would have been substantial (compulsory) adoption of the new RAA and significantly improved availability of compliance enforcement tools for most registrars. The proposed amendments did not receive the requisite two-thirds vote for approval. Staff will continue to engage the GNSO membership to address outstanding concerns raised in the process, to determine whether RAA amendment through this path may still be viable.
The second option for amending the RAA requires Board approval and the voluntary adoption of a revised RAA by registrars. It is anticipated that some forms of incentive would be required to encourage adoption as I previously described.
The third option is the GNSO policy development process that has the ability to modify the terms under which ICANN-accredited registrars do business through the policy development process. In particular, the RAA (at section 4.2: http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.2) allows for the establishment and revision of policies and specifications in the following areas:
4.2.1 issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability, and/or operational stability of Registrar Services, Registry Services, the DNS, or the Internet;
4.2.2 registrar policies reasonably necessary to implement ICANN policies or specifications relating to a DNS registry or to Registry Services;
4.2.3 resolution of disputes concerning the registration of Registered Names (as opposed to the use of such domain names), including where the policies take into account use of the domain names;
4.2.4 principles for allocation of Registered Names (e.g., first-come/first-served, timely renewal, holding period after expiration);
4.2.5 prohibitions on warehousing of or speculation in domain names by registries or registrars;
4.2.6 maintenance of and access to accurate and up-to-date contact information regarding Registered Names and nameservers;
4.2.7 reservation of Registered Names that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of users, (b) intellectual property, or (c) the technical management of the DNS or the Internet (e.g., "example.com" and names with single-letter/digit labels);
4.2.8 procedures to avoid disruptions of registration due to suspension or termination of operations by a registry operator or a registrar, including allocation of responsibility among continuing registrars of the Registered Names sponsored in a TLD by a registrar losing accreditation; and
4.2.9 the transfer of registration data upon a change in registrar sponsoring one or more Registered Names.
These topics mark the boundaries of the "picket fence" within which policy development under the current RAA is possible. (A two-thirds GNSO majority would still be required in order for such policies to be enforceable against registrars, as is the case with the RAA amendment process.)
The current set of proposed amendments, reached through community consultation and negotiation with registrars, would reach several areas that are not ordinarily subject to policy development within the picket fence. Please keep in mind that we are not evaluating the specific amendments, just the realm of potential policy development, and also that our analysis may not have taken all factors into account. In other words, the determination of what's inside the picket fence could conceivably result in a different answer under different circumstances.
The following topics that were included in the original package of amendments sent to the GNSO do appear to fall within the picket fence of potential new obligations that could be imposed on registrars via Consensus Policies:
· Escrow of Whois Privacy/Proxy Customer Data
· Registrant Rights and Responsibilities Document
· Registrar Contractual Relationships with Resellers (where the substantive topic lies within the picket fence)
· Disclosure of Registration Licensee Contact Information
· Registrar Disclosure of Its Own Contact Information
· Operator Skills Training & Testing
· Modification of Data Retention Requirements
Based on our initial review, the following topics that were included in the original package of amendments sent to the GNSO appear to fall outside the picket fence, and therefore could not be imposed on registrars via Consensus Policies:
· Registrar Auditing
· Graduated Sanctions & Accreditation Suspension
· Registrar Group Liability
· Registrar Fees
· Registrations by Registrars (the picket fence allows for policy development related to warehousing of domains by registrars, but the topic addressed by the proposed amendment - requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar for registrar business use - would not be enforceable as a Consensus Policy under the RAA)
· Modification of Arbitration Rights
· Accreditation by Purchase
· Use of ICANN-Accredited Registrars (is a topic appropriate for policy development by the GNSO, but it would not be enforceable through the RAA as a "Consensus Policy")
· Streamlined Requirements for Registrar Notification of New and Revised Consensus Policies
· Removal of References to U.S. Department of Commerce
It is our expectation that the GNSO will continue to evaluate the need for and undertake policy development within the picket fence that would be applicable to all registrars. Nevertheless, we still see strong value to registrants and the greater Internet community in the proposed amendments, even if they cannot be uniformly applied at this time. In the event a system of incentives is implemented to encourage voluntary adoption by registrars, we will, of course, consult with the GNSO and its member-constituencies as we have throughout this process, to solicit input with regard to the most beneficial and meaningful ways and tools to encourage registrar cooperation.
I hope this information is helpful and clear. I will answer what questions I can and get answers to others.
Regards,
Kurt
Kurt Pritz ICANN
4676 Admiralty Way, Ste. 330 Marina del Rey, CA 90292
+1-310-301-5809 (office) +1-310-400-4184 (mobile)
Stephane, Of course we disagree. The RAA is inherently a policy document, as it is applicable to all ICANN-accredited registrars. It is the registrars and ICANN Staff who have tried an "end run around" the GNSO Council and the PDP process, and now apparently are trying to create a "picket fence" where none exists in the RAA. The majority of Council members have found this unacceptable, and my motion simply tries to move forward with some reasonable next steps. Thanks, Mike -----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Stéphane Van Gelder Sent: Thursday, February 19, 2009 10:49 AM To: icann@rodenbaugh.com; Kurt Pritz; council@gnso.icann.org Subject: Re: [council] RAA Amendments Mike, Thanks for clarifying. Under the ICANN Bylaws, the GNSO is a policy-making body and not a body to be drafting contract language to be sent to the Board in an attempt to bind a party to provisions without their consent - especially provisions outside of those enumerated in the contract as the potential subject matter of policies (the picket fence). This appears to be nothing more than a land grab, which is outside the scope of the GNSO. If you want to bind registrars to a new policy on something within the picket fence, go through the PDP process. You appear to be trying to do an end run around the PDP process and the picket fence, however, in violation of ICANN's Bylaws and contracts, and your attempt should be unacceptable to the Council. Stéphane Le 19/02/09 17:47, « Mike Rodenbaugh » <icann@rodenbaugh.com> a écrit :
Stephane,
I agree we should get ICANN Counsel's interpretation as a logical next step in this debate.
The intent of my motion is to have Council agree on a subset of the amendments agreed between ICANN Staff and the Registrars Constituency, and forward that recommendation to the Board for compulsory implementation. Then, the Council would provide guidance as to additional and/or different amendments that the community would like to see made to the RAA, and forward that recommendation to the Board as well.
Thanks, Mike
-----Original Message----- From: Stéphane Van Gelder [mailto:stephane.vangelder@indom.com] Sent: Thursday, February 19, 2009 7:43 AM To: icann@rodenbaugh.com; Kurt Pritz; council@gnso.icann.org Subject: Re: [council] RAA Amendments
Mike,
We obviously disagree with your expansive interpretation of the RAA, and would welcome guidance from the General Counsel on this issue.
Per your motion, would you have the Council formulate and seek to approve amendments to the RAA that are not supported by both of the parties to the contract? In other words, is the intent of your motion to provide guidance to the parties or to have Council move forward and approve changes that it thinks is best?
Thanks.
Stéphane Van Gelder
Le 19/02/09 00:34, « Mike Rodenbaugh » <icann@rodenbaugh.com> a écrit :
Thanks Kurt. You are interpreting the RAA in a very narrow and unprecedented way, as Section 4.2 simply says "policies may be
established
on the following topics..." It does not preclude policy on any other topic. Has ICANN Counsel created this interpretation, or is it simply yours?
Moreover, are these your personal opinions as to what falls within and outside the 'picket fence' that you have now attempted to create? Are they ICANN Counsel's opinions? Who is it ultimately that would make those determinations (if we accepted for the moment that such determinations must be made)? Surely the GNSO Council's collective opinion on any such determination ought to be at least as important as ICANN Staff's, and very well might differ.
In particular, it appears illogical to say that the Council can develop policy on substantive issues, but cannot develop policy to enforce the resulting rules (via notifications to registrars, auditing, sanctions/suspension, etc.).
Also I do not comprehend your attempted distinction between 'policy relating to warehousing' and policy 'requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar'.
Regardless of these concerns, I hope the Council will approve the path forward that I have suggested, so that we can reach consensus as to a package of amendments that can be implemented on a compulsory basis as soon as possible. That motion is on the table for Mexico City, so hopefully Staff will give us its views on that motion as soon as possible, as well as further responses to my specific questions above.
Thanks, Mike
-----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Kurt Pritz Sent: Wednesday, February 18, 2009 11:39 AM To: Council GNSO Subject: [council] RAA Amendments
Dear All:
In follow up to my earlier comments and in response to some of the subsequent discussion by the Council, I thought it might be helpful to clarify the options available to ICANN in modifying registrar obligations under the Registrar Accreditation Agreement (RAA). My earlier comments indicated that two paths were considered to incorporate amendments into the RAA.
There are, of course, three ways by which registrar obligations under the RAA can be modified:
The first option, which is described in the RAA, requires a report, approval by a two-thirds majority of the GNSO, and ICANN Board action. As indicated previously, a new form of RAA adopted based on a two-thirds¹ vote of the Council would take effect upon expiration of each registrar¹s five-year RAA. With over 70% of all registrars' RAAs expiring between 1 June 2009 and 31 May 2011, the result would have been substantial (compulsory) adoption of the new RAA and significantly improved availability of compliance enforcement tools for most registrars. The proposed amendments did not receive the requisite two-thirds vote for approval. Staff will continue to engage the GNSO membership to address outstanding concerns raised in the process, to determine whether RAA amendment through this path may still be viable.
The second option for amending the RAA requires Board approval and the voluntary adoption of a revised RAA by registrars. It is anticipated that some forms of incentive would be required to encourage adoption as I previously described.
The third option is the GNSO policy development process that has the ability to modify the terms under which ICANN-accredited registrars do business through the policy development process. In particular, the RAA (at section 4.2: http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.2) allows for the establishment and revision of policies and specifications in the following areas:
4.2.1 issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability, and/or operational stability of Registrar Services, Registry Services, the DNS, or the Internet;
4.2.2 registrar policies reasonably necessary to implement ICANN policies or specifications relating to a DNS registry or to Registry Services;
4.2.3 resolution of disputes concerning the registration of Registered Names (as opposed to the use of such domain names), including where the policies take into account use of the domain names;
4.2.4 principles for allocation of Registered Names (e.g., first-come/first-served, timely renewal, holding period after expiration);
4.2.5 prohibitions on warehousing of or speculation in domain names by registries or registrars;
4.2.6 maintenance of and access to accurate and up-to-date contact information regarding Registered Names and nameservers;
4.2.7 reservation of Registered Names that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of users, (b) intellectual property, or (c) the technical management of the DNS or the Internet (e.g., "example.com" and names with single-letter/digit labels);
4.2.8 procedures to avoid disruptions of registration due to suspension or termination of operations by a registry operator or a registrar, including allocation of responsibility among continuing registrars of the Registered Names sponsored in a TLD by a registrar losing accreditation; and
4.2.9 the transfer of registration data upon a change in registrar sponsoring one or more Registered Names.
These topics mark the boundaries of the "picket fence" within which policy development under the current RAA is possible. (A two-thirds GNSO majority would still be required in order for such policies to be enforceable against registrars, as is the case with the RAA amendment process.)
The current set of proposed amendments, reached through community consultation and negotiation with registrars, would reach several areas that are not ordinarily subject to policy development within the picket fence. Please keep in mind that we are not evaluating the specific amendments, just the realm of potential policy development, and also that our analysis may not have taken all factors into account. In other words, the determination of what's inside the picket fence could conceivably result in a different answer under different circumstances.
The following topics that were included in the original package of amendments sent to the GNSO do appear to fall within the picket fence of potential new obligations that could be imposed on registrars via Consensus Policies:
· Escrow of Whois Privacy/Proxy Customer Data
· Registrant Rights and Responsibilities Document
· Registrar Contractual Relationships with Resellers (where the substantive topic lies within the picket fence)
· Disclosure of Registration Licensee Contact Information
· Registrar Disclosure of Its Own Contact Information
· Operator Skills Training & Testing
· Modification of Data Retention Requirements
Based on our initial review, the following topics that were included in the original package of amendments sent to the GNSO appear to fall outside the picket fence, and therefore could not be imposed on registrars via Consensus Policies:
· Registrar Auditing
· Graduated Sanctions & Accreditation Suspension
· Registrar Group Liability
· Registrar Fees
· Registrations by Registrars (the picket fence allows for policy development related to warehousing of domains by registrars, but the topic addressed by the proposed amendment - requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar for registrar business use - would not be enforceable as a Consensus Policy under the RAA)
· Modification of Arbitration Rights
· Accreditation by Purchase
· Use of ICANN-Accredited Registrars (is a topic appropriate for policy development by the GNSO, but it would not be enforceable through the RAA as a "Consensus Policy")
· Streamlined Requirements for Registrar Notification of New and Revised Consensus Policies
· Removal of References to U.S. Department of Commerce
It is our expectation that the GNSO will continue to evaluate the need for and undertake policy development within the picket fence that would be applicable to all registrars. Nevertheless, we still see strong value to registrants and the greater Internet community in the proposed amendments, even if they cannot be uniformly applied at this time. In the event a system of incentives is implemented to encourage voluntary adoption by registrars, we will, of course, consult with the GNSO and its member-constituencies as we have throughout this process, to solicit input with regard to the most beneficial and meaningful ways and tools to encourage registrar cooperation.
I hope this information is helpful and clear. I will answer what questions I can and get answers to others.
Regards,
Kurt
Kurt Pritz ICANN
4676 Admiralty Way, Ste. 330 Marina del Rey, CA 90292
+1-310-301-5809 (office) +1-310-400-4184 (mobile)
Stephane, One further point at the moment ... Your argument that "the GNSO is a policy-making body and not a body to be drafting contract language to be sent to the Board in an attempt to bind a party to provisions without their consent" ... Was repeatedly rejected in 2006 by the Registrars Constituency, the GNSO Council and the ICANN Board, in connection with the resolutions relating to "PDP '06" re Registry Contractual Conditions. Thanks, Mike -----Original Message----- From: Mike Rodenbaugh [mailto:icann@rodenbaugh.com] Sent: Thursday, February 19, 2009 11:07 AM To: 'Stéphane Van Gelder'; 'Kurt Pritz'; 'council@gnso.icann.org' Subject: RE: [council] RAA Amendments Stephane, Of course we disagree. The RAA is inherently a policy document, as it is applicable to all ICANN-accredited registrars. It is the registrars and ICANN Staff who have tried an "end run around" the GNSO Council and the PDP process, and now apparently are trying to create a "picket fence" where none exists in the RAA. The majority of Council members have found this unacceptable, and my motion simply tries to move forward with some reasonable next steps. Thanks, Mike -----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Stéphane Van Gelder Sent: Thursday, February 19, 2009 10:49 AM To: icann@rodenbaugh.com; Kurt Pritz; council@gnso.icann.org Subject: Re: [council] RAA Amendments Mike, Thanks for clarifying. Under the ICANN Bylaws, the GNSO is a policy-making body and not a body to be drafting contract language to be sent to the Board in an attempt to bind a party to provisions without their consent - especially provisions outside of those enumerated in the contract as the potential subject matter of policies (the picket fence). This appears to be nothing more than a land grab, which is outside the scope of the GNSO. If you want to bind registrars to a new policy on something within the picket fence, go through the PDP process. You appear to be trying to do an end run around the PDP process and the picket fence, however, in violation of ICANN's Bylaws and contracts, and your attempt should be unacceptable to the Council. Stéphane Le 19/02/09 17:47, « Mike Rodenbaugh » <icann@rodenbaugh.com> a écrit :
Stephane,
I agree we should get ICANN Counsel's interpretation as a logical next step in this debate.
The intent of my motion is to have Council agree on a subset of the amendments agreed between ICANN Staff and the Registrars Constituency, and forward that recommendation to the Board for compulsory implementation. Then, the Council would provide guidance as to additional and/or different amendments that the community would like to see made to the RAA, and forward that recommendation to the Board as well.
Thanks, Mike
-----Original Message----- From: Stéphane Van Gelder [mailto:stephane.vangelder@indom.com] Sent: Thursday, February 19, 2009 7:43 AM To: icann@rodenbaugh.com; Kurt Pritz; council@gnso.icann.org Subject: Re: [council] RAA Amendments
Mike,
We obviously disagree with your expansive interpretation of the RAA, and would welcome guidance from the General Counsel on this issue.
Per your motion, would you have the Council formulate and seek to approve amendments to the RAA that are not supported by both of the parties to the contract? In other words, is the intent of your motion to provide guidance to the parties or to have Council move forward and approve changes that it thinks is best?
Thanks.
Stéphane Van Gelder
Le 19/02/09 00:34, « Mike Rodenbaugh » <icann@rodenbaugh.com> a écrit :
Thanks Kurt. You are interpreting the RAA in a very narrow and unprecedented way, as Section 4.2 simply says "policies may be
established
on the following topics..." It does not preclude policy on any other topic. Has ICANN Counsel created this interpretation, or is it simply yours?
Moreover, are these your personal opinions as to what falls within and outside the 'picket fence' that you have now attempted to create? Are they ICANN Counsel's opinions? Who is it ultimately that would make those determinations (if we accepted for the moment that such determinations must be made)? Surely the GNSO Council's collective opinion on any such determination ought to be at least as important as ICANN Staff's, and very well might differ.
In particular, it appears illogical to say that the Council can develop policy on substantive issues, but cannot develop policy to enforce the resulting rules (via notifications to registrars, auditing, sanctions/suspension, etc.).
Also I do not comprehend your attempted distinction between 'policy relating to warehousing' and policy 'requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar'.
Regardless of these concerns, I hope the Council will approve the path forward that I have suggested, so that we can reach consensus as to a package of amendments that can be implemented on a compulsory basis as soon as possible. That motion is on the table for Mexico City, so hopefully Staff will give us its views on that motion as soon as possible, as well as further responses to my specific questions above.
Thanks, Mike
-----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Kurt Pritz Sent: Wednesday, February 18, 2009 11:39 AM To: Council GNSO Subject: [council] RAA Amendments
Dear All:
In follow up to my earlier comments and in response to some of the subsequent discussion by the Council, I thought it might be helpful to clarify the options available to ICANN in modifying registrar obligations under the Registrar Accreditation Agreement (RAA). My earlier comments indicated that two paths were considered to incorporate amendments into the RAA.
There are, of course, three ways by which registrar obligations under the RAA can be modified:
The first option, which is described in the RAA, requires a report, approval by a two-thirds majority of the GNSO, and ICANN Board action. As indicated previously, a new form of RAA adopted based on a two-thirds¹ vote of the Council would take effect upon expiration of each registrar¹s five-year RAA. With over 70% of all registrars' RAAs expiring between 1 June 2009 and 31 May 2011, the result would have been substantial (compulsory) adoption of the new RAA and significantly improved availability of compliance enforcement tools for most registrars. The proposed amendments did not receive the requisite two-thirds vote for approval. Staff will continue to engage the GNSO membership to address outstanding concerns raised in the process, to determine whether RAA amendment through this path may still be viable.
The second option for amending the RAA requires Board approval and the voluntary adoption of a revised RAA by registrars. It is anticipated that some forms of incentive would be required to encourage adoption as I previously described.
The third option is the GNSO policy development process that has the ability to modify the terms under which ICANN-accredited registrars do business through the policy development process. In particular, the RAA (at section 4.2: http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.2) allows for the establishment and revision of policies and specifications in the following areas:
4.2.1 issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability, and/or operational stability of Registrar Services, Registry Services, the DNS, or the Internet;
4.2.2 registrar policies reasonably necessary to implement ICANN policies or specifications relating to a DNS registry or to Registry Services;
4.2.3 resolution of disputes concerning the registration of Registered Names (as opposed to the use of such domain names), including where the policies take into account use of the domain names;
4.2.4 principles for allocation of Registered Names (e.g., first-come/first-served, timely renewal, holding period after expiration);
4.2.5 prohibitions on warehousing of or speculation in domain names by registries or registrars;
4.2.6 maintenance of and access to accurate and up-to-date contact information regarding Registered Names and nameservers;
4.2.7 reservation of Registered Names that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of users, (b) intellectual property, or (c) the technical management of the DNS or the Internet (e.g., "example.com" and names with single-letter/digit labels);
4.2.8 procedures to avoid disruptions of registration due to suspension or termination of operations by a registry operator or a registrar, including allocation of responsibility among continuing registrars of the Registered Names sponsored in a TLD by a registrar losing accreditation; and
4.2.9 the transfer of registration data upon a change in registrar sponsoring one or more Registered Names.
These topics mark the boundaries of the "picket fence" within which policy development under the current RAA is possible. (A two-thirds GNSO majority would still be required in order for such policies to be enforceable against registrars, as is the case with the RAA amendment process.)
The current set of proposed amendments, reached through community consultation and negotiation with registrars, would reach several areas that are not ordinarily subject to policy development within the picket fence. Please keep in mind that we are not evaluating the specific amendments, just the realm of potential policy development, and also that our analysis may not have taken all factors into account. In other words, the determination of what's inside the picket fence could conceivably result in a different answer under different circumstances.
The following topics that were included in the original package of amendments sent to the GNSO do appear to fall within the picket fence of potential new obligations that could be imposed on registrars via Consensus Policies:
· Escrow of Whois Privacy/Proxy Customer Data
· Registrant Rights and Responsibilities Document
· Registrar Contractual Relationships with Resellers (where the substantive topic lies within the picket fence)
· Disclosure of Registration Licensee Contact Information
· Registrar Disclosure of Its Own Contact Information
· Operator Skills Training & Testing
· Modification of Data Retention Requirements
Based on our initial review, the following topics that were included in the original package of amendments sent to the GNSO appear to fall outside the picket fence, and therefore could not be imposed on registrars via Consensus Policies:
· Registrar Auditing
· Graduated Sanctions & Accreditation Suspension
· Registrar Group Liability
· Registrar Fees
· Registrations by Registrars (the picket fence allows for policy development related to warehousing of domains by registrars, but the topic addressed by the proposed amendment - requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar for registrar business use - would not be enforceable as a Consensus Policy under the RAA)
· Modification of Arbitration Rights
· Accreditation by Purchase
· Use of ICANN-Accredited Registrars (is a topic appropriate for policy development by the GNSO, but it would not be enforceable through the RAA as a "Consensus Policy")
· Streamlined Requirements for Registrar Notification of New and Revised Consensus Policies
· Removal of References to U.S. Department of Commerce
It is our expectation that the GNSO will continue to evaluate the need for and undertake policy development within the picket fence that would be applicable to all registrars. Nevertheless, we still see strong value to registrants and the greater Internet community in the proposed amendments, even if they cannot be uniformly applied at this time. In the event a system of incentives is implemented to encourage voluntary adoption by registrars, we will, of course, consult with the GNSO and its member-constituencies as we have throughout this process, to solicit input with regard to the most beneficial and meaningful ways and tools to encourage registrar cooperation.
I hope this information is helpful and clear. I will answer what questions I can and get answers to others.
Regards,
Kurt
Kurt Pritz ICANN
4676 Admiralty Way, Ste. 330 Marina del Rey, CA 90292
+1-310-301-5809 (office) +1-310-400-4184 (mobile)
Mike, Thank you for your inquiry. Both John Jeffrey and I consulted with Kurt and his team before he sent his note, and we agree with the content. I'm not sure I understand your reading of Section 4 of the RAA. Subsection 4.1 <http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.1> provides that registrars are obligated to comply with new "Consensus Policies" only if (1) the policies are established according to the procedure set forth in subsection 4.3, and (2) the policies are either (4.1.2.1) on one of the topics expressly specified in the agreement or (4.1.2.2) on the list of topics specified in subsection 4.2 (which has been nicknamed the "picket fence"). I believe this interpretation of Section 4 has been consistent over the years; please see for example the October 2002 "General Counsel's Briefing Concerning Implementation of Policies by Registrars and Registry Operators" http://www.icann.org/legal/briefing-on-implementation-20oct02.htm, which stated that "In the consensus-policy provisions of ICANN's existing agreements, registrars and registry operators have agreed to implement policies developed after those agreements are signed only when: 1. The policies are on a topic that is contractually defined as being appropriate for establishment by ICANN S" If you do not agree with the categorization in Kurt's note of which topics are inside and outside the picket fence, that could be a subject for further review and discussion as Kurt's note indicated he was only conveying an "initial review." To clarify the two particular issues you raised, I don't think Kurt said that Consensus Policies could not include enforcement provisions -- that's different though from a hypothetical stand-alone modification to the RAA's notice requirements, which we think would be outside of the picket fence. Similarly, we see a difference between proposed new requirements for domains registered by registrars for the purpose of providing registrar services versus an outright prohibition on warehousing (which would be within the picket fence). I hope this is helpful. Please feel free to let me know if you have any further questions or if I can be of any other assistance. Best regards, Daniel Halloran Deputy General Counsel ICANN
From: Mike Rodenbaugh <icann@rodenbaugh.com> Reply-To: <icann@rodenbaugh.com> Date: Wed, 18 Feb 2009 15:34:48 -0800 To: Kurt Pritz <kurt.pritz@icann.org>, <council@gnso.icann.org> Subject: RE: [council] RAA Amendments
Thanks Kurt. You are interpreting the RAA in a very narrow and unprecedented way, as Section 4.2 simply says "policies may be established on the following topics..." It does not preclude policy on any other topic. Has ICANN Counsel created this interpretation, or is it simply yours?
Moreover, are these your personal opinions as to what falls within and outside the 'picket fence' that you have now attempted to create? Are they ICANN Counsel's opinions? Who is it ultimately that would make those determinations (if we accepted for the moment that such determinations must be made)? Surely the GNSO Council's collective opinion on any such determination ought to be at least as important as ICANN Staff's, and very well might differ.
In particular, it appears illogical to say that the Council can develop policy on substantive issues, but cannot develop policy to enforce the resulting rules (via notifications to registrars, auditing, sanctions/suspension, etc.).
Also I do not comprehend your attempted distinction between 'policy relating to warehousing' and policy 'requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar'.
Regardless of these concerns, I hope the Council will approve the path forward that I have suggested, so that we can reach consensus as to a package of amendments that can be implemented on a compulsory basis as soon as possible. That motion is on the table for Mexico City, so hopefully Staff will give us its views on that motion as soon as possible, as well as further responses to my specific questions above.
Thanks, Mike
-----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Kurt Pritz Sent: Wednesday, February 18, 2009 11:39 AM To: Council GNSO Subject: [council] RAA Amendments
Dear All:
In follow up to my earlier comments and in response to some of the subsequent discussion by the Council, I thought it might be helpful to clarify the options available to ICANN in modifying registrar obligations under the Registrar Accreditation Agreement (RAA). My earlier comments indicated that two paths were considered to incorporate amendments into the RAA.
There are, of course, three ways by which registrar obligations under the RAA can be modified:
The first option, which is described in the RAA, requires a report, approval by a two-thirds majority of the GNSO, and ICANN Board action. As indicated previously, a new form of RAA adopted based on a two-thirds¹ vote of the Council would take effect upon expiration of each registrar¹s five-year RAA. With over 70% of all registrars' RAAs expiring between 1 June 2009 and 31 May 2011, the result would have been substantial (compulsory) adoption of the new RAA and significantly improved availability of compliance enforcement tools for most registrars. The proposed amendments did not receive the requisite two-thirds vote for approval. Staff will continue to engage the GNSO membership to address outstanding concerns raised in the process, to determine whether RAA amendment through this path may still be viable.
The second option for amending the RAA requires Board approval and the voluntary adoption of a revised RAA by registrars. It is anticipated that some forms of incentive would be required to encourage adoption as I previously described.
The third option is the GNSO policy development process that has the ability to modify the terms under which ICANN-accredited registrars do business through the policy development process. In particular, the RAA (at section 4.2: http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.2) allows for the establishment and revision of policies and specifications in the following areas:
4.2.1 issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability, and/or operational stability of Registrar Services, Registry Services, the DNS, or the Internet;
4.2.2 registrar policies reasonably necessary to implement ICANN policies or specifications relating to a DNS registry or to Registry Services;
4.2.3 resolution of disputes concerning the registration of Registered Names (as opposed to the use of such domain names), including where the policies take into account use of the domain names;
4.2.4 principles for allocation of Registered Names (e.g., first-come/first-served, timely renewal, holding period after expiration);
4.2.5 prohibitions on warehousing of or speculation in domain names by registries or registrars;
4.2.6 maintenance of and access to accurate and up-to-date contact information regarding Registered Names and nameservers;
4.2.7 reservation of Registered Names that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of users, (b) intellectual property, or (c) the technical management of the DNS or the Internet (e.g., "example.com" and names with single-letter/digit labels);
4.2.8 procedures to avoid disruptions of registration due to suspension or termination of operations by a registry operator or a registrar, including allocation of responsibility among continuing registrars of the Registered Names sponsored in a TLD by a registrar losing accreditation; and
4.2.9 the transfer of registration data upon a change in registrar sponsoring one or more Registered Names.
These topics mark the boundaries of the "picket fence" within which policy development under the current RAA is possible. (A two-thirds GNSO majority would still be required in order for such policies to be enforceable against registrars, as is the case with the RAA amendment process.)
The current set of proposed amendments, reached through community consultation and negotiation with registrars, would reach several areas that are not ordinarily subject to policy development within the picket fence. Please keep in mind that we are not evaluating the specific amendments, just the realm of potential policy development, and also that our analysis may not have taken all factors into account. In other words, the determination of what's inside the picket fence could conceivably result in a different answer under different circumstances.
The following topics that were included in the original package of amendments sent to the GNSO do appear to fall within the picket fence of potential new obligations that could be imposed on registrars via Consensus Policies:
· Escrow of Whois Privacy/Proxy Customer Data
· Registrant Rights and Responsibilities Document
· Registrar Contractual Relationships with Resellers (where the substantive topic lies within the picket fence)
· Disclosure of Registration Licensee Contact Information
· Registrar Disclosure of Its Own Contact Information
· Operator Skills Training & Testing
· Modification of Data Retention Requirements
Based on our initial review, the following topics that were included in the original package of amendments sent to the GNSO appear to fall outside the picket fence, and therefore could not be imposed on registrars via Consensus Policies:
· Registrar Auditing
· Graduated Sanctions & Accreditation Suspension
· Registrar Group Liability
· Registrar Fees
· Registrations by Registrars (the picket fence allows for policy development related to warehousing of domains by registrars, but the topic addressed by the proposed amendment - requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar for registrar business use - would not be enforceable as a Consensus Policy under the RAA)
· Modification of Arbitration Rights
· Accreditation by Purchase
· Use of ICANN-Accredited Registrars (is a topic appropriate for policy development by the GNSO, but it would not be enforceable through the RAA as a "Consensus Policy")
· Streamlined Requirements for Registrar Notification of New and Revised Consensus Policies
· Removal of References to U.S. Department of Commerce
It is our expectation that the GNSO will continue to evaluate the need for and undertake policy development within the picket fence that would be applicable to all registrars. Nevertheless, we still see strong value to registrants and the greater Internet community in the proposed amendments, even if they cannot be uniformly applied at this time. In the event a system of incentives is implemented to encourage voluntary adoption by registrars, we will, of course, consult with the GNSO and its member-constituencies as we have throughout this process, to solicit input with regard to the most beneficial and meaningful ways and tools to encourage registrar cooperation.
I hope this information is helpful and clear. I will answer what questions I can and get answers to others.
Regards,
Kurt
Kurt Pritz ICANN
4676 Admiralty Way, Ste. 330 Marina del Rey, CA 90292
+1-310-301-5809 (office) +1-310-400-4184 (mobile)
Dan, I interpret this differently. The actual text, with my comments in brackets: Sec. 4.1 4.1 Registrar's Ongoing Obligation to Comply With New or Revised Specifications and Policies. During the Term of this Agreement, Registrar shall comply with the terms of this Agreement on the schedule set forth in Subsection 4.4, with 4.1.1 new or revised specifications (including forms of agreement to which Registrar is a party) and policies established by ICANN as Consensus Policies in the manner described in Subsection 4.3, 4.1.2 in cases where: 4.1.2.1 this Agreement expressly provides for compliance with revised specifications or policies established in the manner set forth in one or more subsections of this Section 4; or 4.1.2.2 the specification or policy concerns one or more topics described in Subsection 4.2. [So I interpret this to plainly mean: Registrar shall comply with ... 4.1.2.1 ... revised specifications or policies established in the manner set forth in . . .] 4.3 Manner of Establishment of New and Revised Specifications and Policies. 4.3.1 "Consensus Policies" are those specifications or policies established based on a consensus among Internet stakeholders represented in the ICANN process, as demonstrated by (a) action of the ICANN Board of Directors establishing the specification or policy, (b) a recommendation, adopted by at least a two-thirds vote of the council of the ICANN Supporting Organization to which the matter is delegated, that the specification or policy should be established, and (c) a written report and supporting materials (which must include all substantive submissions to the Supporting Organization relating to the proposal) that (i) documents the extent of agreement and disagreement among impacted groups, (ii) documents the outreach process used to seek to achieve adequate representation of the views of groups that are likely to be impacted, and (iii) documents the nature and intensity of reasoned support and opposition to the proposed policy. 4.3.2 In the event that Registrar disputes the presence of such a consensus, it shall seek review of that issue from an Independent Review Panel established under ICANN's bylaws. ... [You guys seem to ignore the word "or" between 4.1.2.1 and 4.1.2.2, and the words "one or more" in 4.1.2.1 -- and your interpretation would leave no reason for 4.1.2.1 at all. Section 4.2 does not create any 'picket fence' as it says "may" (not "solely", "only", "limited to" or any such language), and indeed reinforces the above text in its final sentence...] 4.2 Topics for New and Revised Specifications and Policies. New and revised specifications and policies may be established on the following topics: . . . Nothing in this Subsection 4.2 shall limit Registrar's obligations as set forth elsewhere in this Agreement. [The quote you cite from the GC's Briefing in 2002 just makes the point even further, that any resolution that is achieved through Consensus Policy process is contractually defined by Sections 4.1.2.1 and 4.3, and therefore within scope. Nothing in section 4.2 limits the meaning of section 4.3, which is unlimited in scope so long as the process is followed. I guess at very least, this ought to get clarified by amendment to the RAA, while we're doing that otherwise?] Mike Rodenbaugh Rodenbaugh Law 548 Market Street San Francisco, CA 94104 +1.415.738.8087 www.rodenbaugh.com -----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Daniel Halloran Sent: Friday, February 20, 2009 10:32 AM To: icann@rodenbaugh.com; council@gnso.icann.org Subject: Re: [council] RAA Amendments Mike, Thank you for your inquiry. Both John Jeffrey and I consulted with Kurt and his team before he sent his note, and we agree with the content. I'm not sure I understand your reading of Section 4 of the RAA. Subsection 4.1 <http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.1> provides that registrars are obligated to comply with new "Consensus Policies" only if (1) the policies are established according to the procedure set forth in subsection 4.3, and (2) the policies are either (4.1.2.1) on one of the topics expressly specified in the agreement or (4.1.2.2) on the list of topics specified in subsection 4.2 (which has been nicknamed the "picket fence"). I believe this interpretation of Section 4 has been consistent over the years; please see for example the October 2002 "General Counsel's Briefing Concerning Implementation of Policies by Registrars and Registry Operators" http://www.icann.org/legal/briefing-on-implementation-20oct02.htm, which stated that "In the consensus-policy provisions of ICANN's existing agreements, registrars and registry operators have agreed to implement policies developed after those agreements are signed only when: 1. The policies are on a topic that is contractually defined as being appropriate for establishment by ICANN S" If you do not agree with the categorization in Kurt's note of which topics are inside and outside the picket fence, that could be a subject for further review and discussion as Kurt's note indicated he was only conveying an "initial review." To clarify the two particular issues you raised, I don't think Kurt said that Consensus Policies could not include enforcement provisions -- that's different though from a hypothetical stand-alone modification to the RAA's notice requirements, which we think would be outside of the picket fence. Similarly, we see a difference between proposed new requirements for domains registered by registrars for the purpose of providing registrar services versus an outright prohibition on warehousing (which would be within the picket fence). I hope this is helpful. Please feel free to let me know if you have any further questions or if I can be of any other assistance. Best regards, Daniel Halloran Deputy General Counsel ICANN
From: Mike Rodenbaugh <icann@rodenbaugh.com> Reply-To: <icann@rodenbaugh.com> Date: Wed, 18 Feb 2009 15:34:48 -0800 To: Kurt Pritz <kurt.pritz@icann.org>, <council@gnso.icann.org> Subject: RE: [council] RAA Amendments
Thanks Kurt. You are interpreting the RAA in a very narrow and unprecedented way, as Section 4.2 simply says "policies may be established on the following topics..." It does not preclude policy on any other topic. Has ICANN Counsel created this interpretation, or is it simply yours?
Moreover, are these your personal opinions as to what falls within and outside the 'picket fence' that you have now attempted to create? Are they ICANN Counsel's opinions? Who is it ultimately that would make those determinations (if we accepted for the moment that such determinations must be made)? Surely the GNSO Council's collective opinion on any such determination ought to be at least as important as ICANN Staff's, and very well might differ.
In particular, it appears illogical to say that the Council can develop policy on substantive issues, but cannot develop policy to enforce the resulting rules (via notifications to registrars, auditing, sanctions/suspension, etc.).
Also I do not comprehend your attempted distinction between 'policy relating to warehousing' and policy 'requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar'.
Regardless of these concerns, I hope the Council will approve the path forward that I have suggested, so that we can reach consensus as to a package of amendments that can be implemented on a compulsory basis as soon as possible. That motion is on the table for Mexico City, so hopefully Staff will give us its views on that motion as soon as possible, as well as further responses to my specific questions above.
Thanks, Mike
-----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Kurt Pritz Sent: Wednesday, February 18, 2009 11:39 AM To: Council GNSO Subject: [council] RAA Amendments
Dear All:
In follow up to my earlier comments and in response to some of the subsequent discussion by the Council, I thought it might be helpful to clarify the options available to ICANN in modifying registrar obligations under the Registrar Accreditation Agreement (RAA). My earlier comments indicated that two paths were considered to incorporate amendments into the RAA.
There are, of course, three ways by which registrar obligations under the RAA can be modified:
The first option, which is described in the RAA, requires a report, approval by a two-thirds majority of the GNSO, and ICANN Board action. As indicated previously, a new form of RAA adopted based on a two-thirds¹ vote of the Council would take effect upon expiration of each registrar¹s five-year RAA. With over 70% of all registrars' RAAs expiring between 1 June 2009 and 31 May 2011, the result would have been substantial (compulsory) adoption of the new RAA and significantly improved availability of compliance enforcement tools for most registrars. The proposed amendments did not receive the requisite two-thirds vote for approval. Staff will continue to engage the GNSO membership to address outstanding concerns raised in the process, to determine whether RAA amendment through this path may still be viable.
The second option for amending the RAA requires Board approval and the voluntary adoption of a revised RAA by registrars. It is anticipated that some forms of incentive would be required to encourage adoption as I previously described.
The third option is the GNSO policy development process that has the ability to modify the terms under which ICANN-accredited registrars do business through the policy development process. In particular, the RAA (at section 4.2: http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.2) allows for the establishment and revision of policies and specifications in the following areas:
4.2.1 issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability, and/or operational stability of Registrar Services, Registry Services, the DNS, or the Internet;
4.2.2 registrar policies reasonably necessary to implement ICANN policies or specifications relating to a DNS registry or to Registry Services;
4.2.3 resolution of disputes concerning the registration of Registered Names (as opposed to the use of such domain names), including where the policies take into account use of the domain names;
4.2.4 principles for allocation of Registered Names (e.g., first-come/first-served, timely renewal, holding period after expiration);
4.2.5 prohibitions on warehousing of or speculation in domain names by registries or registrars;
4.2.6 maintenance of and access to accurate and up-to-date contact information regarding Registered Names and nameservers;
4.2.7 reservation of Registered Names that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of users, (b) intellectual property, or (c) the technical management of the DNS or the Internet (e.g., "example.com" and names with single-letter/digit labels);
4.2.8 procedures to avoid disruptions of registration due to suspension or termination of operations by a registry operator or a registrar, including allocation of responsibility among continuing registrars of the Registered Names sponsored in a TLD by a registrar losing accreditation; and
4.2.9 the transfer of registration data upon a change in registrar sponsoring one or more Registered Names.
These topics mark the boundaries of the "picket fence" within which policy development under the current RAA is possible. (A two-thirds GNSO majority would still be required in order for such policies to be enforceable against registrars, as is the case with the RAA amendment process.)
The current set of proposed amendments, reached through community consultation and negotiation with registrars, would reach several areas that are not ordinarily subject to policy development within the picket fence. Please keep in mind that we are not evaluating the specific amendments, just the realm of potential policy development, and also that our analysis may not have taken all factors into account. In other words, the determination of what's inside the picket fence could conceivably result in a different answer under different circumstances.
The following topics that were included in the original package of amendments sent to the GNSO do appear to fall within the picket fence of potential new obligations that could be imposed on registrars via Consensus Policies:
· Escrow of Whois Privacy/Proxy Customer Data
· Registrant Rights and Responsibilities Document
· Registrar Contractual Relationships with Resellers (where the substantive topic lies within the picket fence)
· Disclosure of Registration Licensee Contact Information
· Registrar Disclosure of Its Own Contact Information
· Operator Skills Training & Testing
· Modification of Data Retention Requirements
Based on our initial review, the following topics that were included in the original package of amendments sent to the GNSO appear to fall outside the picket fence, and therefore could not be imposed on registrars via Consensus Policies:
· Registrar Auditing
· Graduated Sanctions & Accreditation Suspension
· Registrar Group Liability
· Registrar Fees
· Registrations by Registrars (the picket fence allows for policy development related to warehousing of domains by registrars, but the topic addressed by the proposed amendment - requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar for registrar business use - would not be enforceable as a Consensus Policy under the RAA)
· Modification of Arbitration Rights
· Accreditation by Purchase
· Use of ICANN-Accredited Registrars (is a topic appropriate for policy development by the GNSO, but it would not be enforceable through the RAA as a "Consensus Policy")
· Streamlined Requirements for Registrar Notification of New and Revised Consensus Policies
· Removal of References to U.S. Department of Commerce
It is our expectation that the GNSO will continue to evaluate the need for and undertake policy development within the picket fence that would be applicable to all registrars. Nevertheless, we still see strong value to registrants and the greater Internet community in the proposed amendments, even if they cannot be uniformly applied at this time. In the event a system of incentives is implemented to encourage voluntary adoption by registrars, we will, of course, consult with the GNSO and its member-constituencies as we have throughout this process, to solicit input with regard to the most beneficial and meaningful ways and tools to encourage registrar cooperation.
I hope this information is helpful and clear. I will answer what questions I can and get answers to others.
Regards,
Kurt
Kurt Pritz ICANN
4676 Admiralty Way, Ste. 330 Marina del Rey, CA 90292
+1-310-301-5809 (office) +1-310-400-4184 (mobile)
Mike, Thanks for your note. I read it carefully, but I still don't agree with your interpretation. It might be better to pick this conversation up again in Mexico when we can look at the same screen and discuss this in person? Also, I'm not sure how useful this discussion really is in the context of the proposed amendment to the RAA itself. As indicated in other briefings to the Council, RAA subsection 5.4 provides that a revised form of the RAA can be implemented upon the renewal of each registrar's five-year accreditation term if the revisions to the form of the RAA are established according to the procedure set forth in subsection 4.3, so if a supermajority of the GNSO recommends the package of amendments to the RAA then that new form of RAA could be made effective without the need for any "picket fence" analysis of the particular changes to the agreement. Anyway, I agree that it can be difficult to parse RAA subsection 4.1. I think that part of the difficulty arises from the fact that subsection 4.1 is actually one big sentence that has been broken-up and spread across several sub-subsections. In case it might be useful, here's a copy of the complete text of the sentence that is expressed in 4.1 without the line breaks for each subsection: "[4.1] During the Term of this Agreement, Registrar shall comply with the terms of this Agreement on the schedule set forth in Subsection 4.4, with [4.1.1] new or revised specifications (including forms of agreement to which Registrar is a party) and policies established by ICANN as Consensus Policies in the manner described in Subsection 4.3, [4.1.2] in cases where: [4.1.2.1] this Agreement expressly provides for compliance with revised specifications or policies established in the manner set forth in one or more subsections of this Section 4; or [4.1.2.2] the specification or policy concerns one or more topics described in Subsection 4.2." (I hesitate to use ellipses to try to explain an interpretation of an agreement, but since you've given it a try I will too. I think the relevant operative text from 4.1 would read as follows: "… Registrar shall comply with … Consensus Policies … [4.1.2] in cases where: [4.1.2.1] this Agreement expressly provides for compliance with revised specifications or policies … or [4.1.2.2] the specification or policy concerns one or more topics described in Subsection 4.2.") To restate my understanding, RAA subsection 4.1.2 provides that registrars are obligated to comply with policies only in cases where the policy is on one of the topics covered by either 4.1.2.1 or 4.1.2.2. The topics covered by 4.1.2.1 are a limited number of places within the RAA (at least subsections 3.3.4, 3.3.8, 3.7.5, 3.7.8, 3.7.9) that expressly identify particular topics for revised specifications or policies. The topics covered by 4.1.2.1 are the topics identified in 4.2 (a.k.a. "the picket fence"). This interpretation seems to me to be consistent with the 2002 memo to the Council that I cited, which stated that registrars and registry operators have agreed to implement policies only when the policies are on a topic that is contractually defined as being appropriate for establishment by ICANN. I have reviewed and re-confirmed my interpretation of the RAA with Kurt Pritz and his team, and with John Jeffrey. Still, I'd be happy to meet with you in Mexico and continue to discuss this in as much detail as you'd like. I look forward to seeing you there. Best regards, Dan ________________________________________ From: owner-council@gnso.icann.org [owner-council@gnso.icann.org] On Behalf Of Mike Rodenbaugh [icann@rodenbaugh.com] Sent: Monday, February 23, 2009 23:55 To: Daniel Halloran; council@gnso.icann.org Subject: RE: [council] RAA Amendments Dan, I interpret this differently. The actual text, with my comments in brackets: Sec. 4.1 4.1 Registrar's Ongoing Obligation to Comply With New or Revised Specifications and Policies. During the Term of this Agreement, Registrar shall comply with the terms of this Agreement on the schedule set forth in Subsection 4.4, with 4.1.1 new or revised specifications (including forms of agreement to which Registrar is a party) and policies established by ICANN as Consensus Policies in the manner described in Subsection 4.3, 4.1.2 in cases where: 4.1.2.1 this Agreement expressly provides for compliance with revised specifications or policies established in the manner set forth in one or more subsections of this Section 4; or 4.1.2.2 the specification or policy concerns one or more topics described in Subsection 4.2. [So I interpret this to plainly mean: Registrar shall comply with ... 4.1.2.1 ... revised specifications or policies established in the manner set forth in . . .] 4.3 Manner of Establishment of New and Revised Specifications and Policies. 4.3.1 "Consensus Policies" are those specifications or policies established based on a consensus among Internet stakeholders represented in the ICANN process, as demonstrated by (a) action of the ICANN Board of Directors establishing the specification or policy, (b) a recommendation, adopted by at least a two-thirds vote of the council of the ICANN Supporting Organization to which the matter is delegated, that the specification or policy should be established, and (c) a written report and supporting materials (which must include all substantive submissions to the Supporting Organization relating to the proposal) that (i) documents the extent of agreement and disagreement among impacted groups, (ii) documents the outreach process used to seek to achieve adequate representation of the views of groups that are likely to be impacted, and (iii) documents the nature and intensity of reasoned support and opposition to the proposed policy. 4.3.2 In the event that Registrar disputes the presence of such a consensus, it shall seek review of that issue from an Independent Review Panel established under ICANN's bylaws. ... [You guys seem to ignore the word "or" between 4.1.2.1 and 4.1.2.2, and the words "one or more" in 4.1.2.1 -- and your interpretation would leave no reason for 4.1.2.1 at all. Section 4.2 does not create any 'picket fence' as it says "may" (not "solely", "only", "limited to" or any such language), and indeed reinforces the above text in its final sentence...] 4.2 Topics for New and Revised Specifications and Policies. New and revised specifications and policies may be established on the following topics: . . . Nothing in this Subsection 4.2 shall limit Registrar's obligations as set forth elsewhere in this Agreement. [The quote you cite from the GC's Briefing in 2002 just makes the point even further, that any resolution that is achieved through Consensus Policy process is contractually defined by Sections 4.1.2.1 and 4.3, and therefore within scope. Nothing in section 4.2 limits the meaning of section 4.3, which is unlimited in scope so long as the process is followed. I guess at very least, this ought to get clarified by amendment to the RAA, while we're doing that otherwise?] Mike Rodenbaugh Rodenbaugh Law 548 Market Street San Francisco, CA 94104 +1.415.738.8087 www.rodenbaugh.com -----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Daniel Halloran Sent: Friday, February 20, 2009 10:32 AM To: icann@rodenbaugh.com; council@gnso.icann.org Subject: Re: [council] RAA Amendments Mike, Thank you for your inquiry. Both John Jeffrey and I consulted with Kurt and his team before he sent his note, and we agree with the content. I'm not sure I understand your reading of Section 4 of the RAA. Subsection 4.1 <http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.1> provides that registrars are obligated to comply with new "Consensus Policies" only if (1) the policies are established according to the procedure set forth in subsection 4.3, and (2) the policies are either (4.1.2.1) on one of the topics expressly specified in the agreement or (4.1.2.2) on the list of topics specified in subsection 4.2 (which has been nicknamed the "picket fence"). I believe this interpretation of Section 4 has been consistent over the years; please see for example the October 2002 "General Counsel's Briefing Concerning Implementation of Policies by Registrars and Registry Operators" http://www.icann.org/legal/briefing-on-implementation-20oct02.htm, which stated that "In the consensus-policy provisions of ICANN's existing agreements, registrars and registry operators have agreed to implement policies developed after those agreements are signed only when: 1. The policies are on a topic that is contractually defined as being appropriate for establishment by ICANN S" If you do not agree with the categorization in Kurt's note of which topics are inside and outside the picket fence, that could be a subject for further review and discussion as Kurt's note indicated he was only conveying an "initial review." To clarify the two particular issues you raised, I don't think Kurt said that Consensus Policies could not include enforcement provisions -- that's different though from a hypothetical stand-alone modification to the RAA's notice requirements, which we think would be outside of the picket fence. Similarly, we see a difference between proposed new requirements for domains registered by registrars for the purpose of providing registrar services versus an outright prohibition on warehousing (which would be within the picket fence). I hope this is helpful. Please feel free to let me know if you have any further questions or if I can be of any other assistance. Best regards, Daniel Halloran Deputy General Counsel ICANN
From: Mike Rodenbaugh <icann@rodenbaugh.com> Reply-To: <icann@rodenbaugh.com> Date: Wed, 18 Feb 2009 15:34:48 -0800 To: Kurt Pritz <kurt.pritz@icann.org>, <council@gnso.icann.org> Subject: RE: [council] RAA Amendments
Thanks Kurt. You are interpreting the RAA in a very narrow and unprecedented way, as Section 4.2 simply says "policies may be established on the following topics..." It does not preclude policy on any other topic. Has ICANN Counsel created this interpretation, or is it simply yours?
Moreover, are these your personal opinions as to what falls within and outside the 'picket fence' that you have now attempted to create? Are they ICANN Counsel's opinions? Who is it ultimately that would make those determinations (if we accepted for the moment that such determinations must be made)? Surely the GNSO Council's collective opinion on any such determination ought to be at least as important as ICANN Staff's, and very well might differ.
In particular, it appears illogical to say that the Council can develop policy on substantive issues, but cannot develop policy to enforce the resulting rules (via notifications to registrars, auditing, sanctions/suspension, etc.).
Also I do not comprehend your attempted distinction between 'policy relating to warehousing' and policy 'requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar'.
Regardless of these concerns, I hope the Council will approve the path forward that I have suggested, so that we can reach consensus as to a package of amendments that can be implemented on a compulsory basis as soon as possible. That motion is on the table for Mexico City, so hopefully Staff will give us its views on that motion as soon as possible, as well as further responses to my specific questions above.
Thanks, Mike
-----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Kurt Pritz Sent: Wednesday, February 18, 2009 11:39 AM To: Council GNSO Subject: [council] RAA Amendments
Dear All:
In follow up to my earlier comments and in response to some of the subsequent discussion by the Council, I thought it might be helpful to clarify the options available to ICANN in modifying registrar obligations under the Registrar Accreditation Agreement (RAA). My earlier comments indicated that two paths were considered to incorporate amendments into the RAA.
There are, of course, three ways by which registrar obligations under the RAA can be modified:
The first option, which is described in the RAA, requires a report, approval by a two-thirds majority of the GNSO, and ICANN Board action. As indicated previously, a new form of RAA adopted based on a two-thirds¹ vote of the Council would take effect upon expiration of each registrar¹s five-year RAA. With over 70% of all registrars' RAAs expiring between 1 June 2009 and 31 May 2011, the result would have been substantial (compulsory) adoption of the new RAA and significantly improved availability of compliance enforcement tools for most registrars. The proposed amendments did not receive the requisite two-thirds vote for approval. Staff will continue to engage the GNSO membership to address outstanding concerns raised in the process, to determine whether RAA amendment through this path may still be viable.
The second option for amending the RAA requires Board approval and the voluntary adoption of a revised RAA by registrars. It is anticipated that some forms of incentive would be required to encourage adoption as I previously described.
The third option is the GNSO policy development process that has the ability to modify the terms under which ICANN-accredited registrars do business through the policy development process. In particular, the RAA (at section 4.2: http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.2) allows for the establishment and revision of policies and specifications in the following areas:
4.2.1 issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability, and/or operational stability of Registrar Services, Registry Services, the DNS, or the Internet;
4.2.2 registrar policies reasonably necessary to implement ICANN policies or specifications relating to a DNS registry or to Registry Services;
4.2.3 resolution of disputes concerning the registration of Registered Names (as opposed to the use of such domain names), including where the policies take into account use of the domain names;
4.2.4 principles for allocation of Registered Names (e.g., first-come/first-served, timely renewal, holding period after expiration);
4.2.5 prohibitions on warehousing of or speculation in domain names by registries or registrars;
4.2.6 maintenance of and access to accurate and up-to-date contact information regarding Registered Names and nameservers;
4.2.7 reservation of Registered Names that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of users, (b) intellectual property, or (c) the technical management of the DNS or the Internet (e.g., "example.com" and names with single-letter/digit labels);
4.2.8 procedures to avoid disruptions of registration due to suspension or termination of operations by a registry operator or a registrar, including allocation of responsibility among continuing registrars of the Registered Names sponsored in a TLD by a registrar losing accreditation; and
4.2.9 the transfer of registration data upon a change in registrar sponsoring one or more Registered Names.
These topics mark the boundaries of the "picket fence" within which policy development under the current RAA is possible. (A two-thirds GNSO majority would still be required in order for such policies to be enforceable against registrars, as is the case with the RAA amendment process.)
The current set of proposed amendments, reached through community consultation and negotiation with registrars, would reach several areas that are not ordinarily subject to policy development within the picket fence. Please keep in mind that we are not evaluating the specific amendments, just the realm of potential policy development, and also that our analysis may not have taken all factors into account. In other words, the determination of what's inside the picket fence could conceivably result in a different answer under different circumstances.
The following topics that were included in the original package of amendments sent to the GNSO do appear to fall within the picket fence of potential new obligations that could be imposed on registrars via Consensus Policies:
· Escrow of Whois Privacy/Proxy Customer Data
· Registrant Rights and Responsibilities Document
· Registrar Contractual Relationships with Resellers (where the substantive topic lies within the picket fence)
· Disclosure of Registration Licensee Contact Information
· Registrar Disclosure of Its Own Contact Information
· Operator Skills Training & Testing
· Modification of Data Retention Requirements
Based on our initial review, the following topics that were included in the original package of amendments sent to the GNSO appear to fall outside the picket fence, and therefore could not be imposed on registrars via Consensus Policies:
· Registrar Auditing
· Graduated Sanctions & Accreditation Suspension
· Registrar Group Liability
· Registrar Fees
· Registrations by Registrars (the picket fence allows for policy development related to warehousing of domains by registrars, but the topic addressed by the proposed amendment - requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar for registrar business use - would not be enforceable as a Consensus Policy under the RAA)
· Modification of Arbitration Rights
· Accreditation by Purchase
· Use of ICANN-Accredited Registrars (is a topic appropriate for policy development by the GNSO, but it would not be enforceable through the RAA as a "Consensus Policy")
· Streamlined Requirements for Registrar Notification of New and Revised Consensus Policies
· Removal of References to U.S. Department of Commerce
It is our expectation that the GNSO will continue to evaluate the need for and undertake policy development within the picket fence that would be applicable to all registrars. Nevertheless, we still see strong value to registrants and the greater Internet community in the proposed amendments, even if they cannot be uniformly applied at this time. In the event a system of incentives is implemented to encourage voluntary adoption by registrars, we will, of course, consult with the GNSO and its member-constituencies as we have throughout this process, to solicit input with regard to the most beneficial and meaningful ways and tools to encourage registrar cooperation.
I hope this information is helpful and clear. I will answer what questions I can and get answers to others.
Regards,
Kurt
Kurt Pritz ICANN
4676 Admiralty Way, Ste. 330 Marina del Rey, CA 90292
+1-310-301-5809 (office) +1-310-400-4184 (mobile)
Dan, During the Council's 29 January meeting, I had asked about the ability to go forward under Section 4.3.4. Kurt indicated that he would want to consult with you and John. Because this provision is of interest to a number of people who will be in Mexico City or on the phone, would it be possible to include this provision in the Saturday discussion? Many thanks. Kristina -----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Daniel Halloran Sent: Wednesday, February 25, 2009 4:11 PM To: icann@rodenbaugh.com; council@gnso.icann.org Subject: RE: [council] RAA Amendments Mike, Thanks for your note. I read it carefully, but I still don't agree with your interpretation. It might be better to pick this conversation up again in Mexico when we can look at the same screen and discuss this in person? Also, I'm not sure how useful this discussion really is in the context of the proposed amendment to the RAA itself. As indicated in other briefings to the Council, RAA subsection 5.4 provides that a revised form of the RAA can be implemented upon the renewal of each registrar's five-year accreditation term if the revisions to the form of the RAA are established according to the procedure set forth in subsection 4.3, so if a supermajority of the GNSO recommends the package of amendments to the RAA then that new form of RAA could be made effective without the need for any "picket fence" analysis of the particular changes to the agreement. Anyway, I agree that it can be difficult to parse RAA subsection 4.1. I think that part of the difficulty arises from the fact that subsection 4.1 is actually one big sentence that has been broken-up and spread across several sub-subsections. In case it might be useful, here's a copy of the complete text of the sentence that is expressed in 4.1 without the line breaks for each subsection: "[4.1] During the Term of this Agreement, Registrar shall comply with the terms of this Agreement on the schedule set forth in Subsection 4.4, with [4.1.1] new or revised specifications (including forms of agreement to which Registrar is a party) and policies established by ICANN as Consensus Policies in the manner described in Subsection 4.3, [4.1.2] in cases where: [4.1.2.1] this Agreement expressly provides for compliance with revised specifications or policies established in the manner set forth in one or more subsections of this Section 4; or [4.1.2.2] the specification or policy concerns one or more topics described in Subsection 4.2." (I hesitate to use ellipses to try to explain an interpretation of an agreement, but since you've given it a try I will too. I think the relevant operative text from 4.1 would read as follows: "... Registrar shall comply with ... Consensus Policies ... [4.1.2] in cases where: [4.1.2.1] this Agreement expressly provides for compliance with revised specifications or policies ... or [4.1.2.2] the specification or policy concerns one or more topics described in Subsection 4.2.") To restate my understanding, RAA subsection 4.1.2 provides that registrars are obligated to comply with policies only in cases where the policy is on one of the topics covered by either 4.1.2.1 or 4.1.2.2. The topics covered by 4.1.2.1 are a limited number of places within the RAA (at least subsections 3.3.4, 3.3.8, 3.7.5, 3.7.8, 3.7.9) that expressly identify particular topics for revised specifications or policies. The topics covered by 4.1.2.1 are the topics identified in 4.2 (a.k.a. "the picket fence"). This interpretation seems to me to be consistent with the 2002 memo to the Council that I cited, which stated that registrars and registry operators have agreed to implement policies only when the policies are on a topic that is contractually defined as being appropriate for establishment by ICANN. I have reviewed and re-confirmed my interpretation of the RAA with Kurt Pritz and his team, and with John Jeffrey. Still, I'd be happy to meet with you in Mexico and continue to discuss this in as much detail as you'd like. I look forward to seeing you there. Best regards, Dan ________________________________________ From: owner-council@gnso.icann.org [owner-council@gnso.icann.org] On Behalf Of Mike Rodenbaugh [icann@rodenbaugh.com] Sent: Monday, February 23, 2009 23:55 To: Daniel Halloran; council@gnso.icann.org Subject: RE: [council] RAA Amendments Dan, I interpret this differently. The actual text, with my comments in brackets: Sec. 4.1 4.1 Registrar's Ongoing Obligation to Comply With New or Revised Specifications and Policies. During the Term of this Agreement, Registrar shall comply with the terms of this Agreement on the schedule set forth in Subsection 4.4, with 4.1.1 new or revised specifications (including forms of agreement to which Registrar is a party) and policies established by ICANN as Consensus Policies in the manner described in Subsection 4.3, 4.1.2 in cases where: 4.1.2.1 this Agreement expressly provides for compliance with revised specifications or policies established in the manner set forth in one or more subsections of this Section 4; or 4.1.2.2 the specification or policy concerns one or more topics described in Subsection 4.2. [So I interpret this to plainly mean: Registrar shall comply with ... 4.1.2.1 ... revised specifications or policies established in the manner set forth in . . .] 4.3 Manner of Establishment of New and Revised Specifications and Policies. 4.3.1 "Consensus Policies" are those specifications or policies established based on a consensus among Internet stakeholders represented in the ICANN process, as demonstrated by (a) action of the ICANN Board of Directors establishing the specification or policy, (b) a recommendation, adopted by at least a two-thirds vote of the council of the ICANN Supporting Organization to which the matter is delegated, that the specification or policy should be established, and (c) a written report and supporting materials (which must include all substantive submissions to the Supporting Organization relating to the proposal) that (i) documents the extent of agreement and disagreement among impacted groups, (ii) documents the outreach process used to seek to achieve adequate representation of the views of groups that are likely to be impacted, and (iii) documents the nature and intensity of reasoned support and opposition to the proposed policy. 4.3.2 In the event that Registrar disputes the presence of such a consensus, it shall seek review of that issue from an Independent Review Panel established under ICANN's bylaws. ... [You guys seem to ignore the word "or" between 4.1.2.1 and 4.1.2.2, and the words "one or more" in 4.1.2.1 -- and your interpretation would leave no reason for 4.1.2.1 at all. Section 4.2 does not create any 'picket fence' as it says "may" (not "solely", "only", "limited to" or any such language), and indeed reinforces the above text in its final sentence...] 4.2 Topics for New and Revised Specifications and Policies. New and revised specifications and policies may be established on the following topics: . . . Nothing in this Subsection 4.2 shall limit Registrar's obligations as set forth elsewhere in this Agreement. [The quote you cite from the GC's Briefing in 2002 just makes the point even further, that any resolution that is achieved through Consensus Policy process is contractually defined by Sections 4.1.2.1 and 4.3, and therefore within scope. Nothing in section 4.2 limits the meaning of section 4.3, which is unlimited in scope so long as the process is followed. I guess at very least, this ought to get clarified by amendment to the RAA, while we're doing that otherwise?] Mike Rodenbaugh Rodenbaugh Law 548 Market Street San Francisco, CA 94104 +1.415.738.8087 www.rodenbaugh.com -----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Daniel Halloran Sent: Friday, February 20, 2009 10:32 AM To: icann@rodenbaugh.com; council@gnso.icann.org Subject: Re: [council] RAA Amendments Mike, Thank you for your inquiry. Both John Jeffrey and I consulted with Kurt and his team before he sent his note, and we agree with the content. I'm not sure I understand your reading of Section 4 of the RAA. Subsection 4.1 <http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.1> provides that registrars are obligated to comply with new "Consensus Policies" only if (1) the policies are established according to the procedure set forth in subsection 4.3, and (2) the policies are either (4.1.2.1) on one of the topics expressly specified in the agreement or (4.1.2.2) on the list of topics specified in subsection 4.2 (which has been nicknamed the "picket fence"). I believe this interpretation of Section 4 has been consistent over the years; please see for example the October 2002 "General Counsel's Briefing Concerning Implementation of Policies by Registrars and Registry Operators" http://www.icann.org/legal/briefing-on-implementation-20oct02.htm, which stated that "In the consensus-policy provisions of ICANN's existing agreements, registrars and registry operators have agreed to implement policies developed after those agreements are signed only when: 1. The policies are on a topic that is contractually defined as being appropriate for establishment by ICANN S" If you do not agree with the categorization in Kurt's note of which topics are inside and outside the picket fence, that could be a subject for further review and discussion as Kurt's note indicated he was only conveying an "initial review." To clarify the two particular issues you raised, I don't think Kurt said that Consensus Policies could not include enforcement provisions -- that's different though from a hypothetical stand-alone modification to the RAA's notice requirements, which we think would be outside of the picket fence. Similarly, we see a difference between proposed new requirements for domains registered by registrars for the purpose of providing registrar services versus an outright prohibition on warehousing (which would be within the picket fence). I hope this is helpful. Please feel free to let me know if you have any further questions or if I can be of any other assistance. Best regards, Daniel Halloran Deputy General Counsel ICANN
From: Mike Rodenbaugh <icann@rodenbaugh.com> Reply-To: <icann@rodenbaugh.com> Date: Wed, 18 Feb 2009 15:34:48 -0800 To: Kurt Pritz <kurt.pritz@icann.org>, <council@gnso.icann.org> Subject: RE: [council] RAA Amendments
Thanks Kurt. You are interpreting the RAA in a very narrow and unprecedented way, as Section 4.2 simply says "policies may be established on the following topics..." It does not preclude policy on any other topic. Has ICANN Counsel created this interpretation, or is it simply yours?
Moreover, are these your personal opinions as to what falls within and outside the 'picket fence' that you have now attempted to create? Are they ICANN Counsel's opinions? Who is it ultimately that would make those determinations (if we accepted for the moment that such determinations must be made)? Surely the GNSO Council's collective opinion on any such determination ought to be at least as important as ICANN Staff's, and very well might differ.
In particular, it appears illogical to say that the Council can develop policy on substantive issues, but cannot develop policy to enforce the resulting rules (via notifications to registrars, auditing, sanctions/suspension, etc.).
Also I do not comprehend your attempted distinction between 'policy relating to warehousing' and policy 'requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar'.
Regardless of these concerns, I hope the Council will approve the path forward that I have suggested, so that we can reach consensus as to a package of amendments that can be implemented on a compulsory basis as soon as possible. That motion is on the table for Mexico City, so hopefully Staff will give us its views on that motion as soon as possible, as well as further responses to my specific questions above.
Thanks, Mike
-----Original Message----- From: owner-council@gnso.icann.org [mailto:owner-council@gnso.icann.org] On Behalf Of Kurt Pritz Sent: Wednesday, February 18, 2009 11:39 AM To: Council GNSO Subject: [council] RAA Amendments
Dear All:
In follow up to my earlier comments and in response to some of the subsequent discussion by the Council, I thought it might be helpful to clarify the options available to ICANN in modifying registrar obligations under the Registrar Accreditation Agreement (RAA). My earlier comments indicated that two paths were considered to incorporate amendments into the RAA.
There are, of course, three ways by which registrar obligations under the RAA can be modified:
The first option, which is described in the RAA, requires a report, approval by a two-thirds majority of the GNSO, and ICANN Board action. As indicated previously, a new form of RAA adopted based on a two-thirds¹ vote of the Council would take effect upon expiration of each registrar¹s five-year RAA. With over 70% of all registrars' RAAs expiring between 1 June 2009 and 31 May 2011, the result would have been substantial (compulsory) adoption of the new RAA and significantly improved availability of compliance enforcement tools for most registrars. The proposed amendments did not receive the requisite two-thirds vote for approval. Staff will continue to engage the GNSO membership to address outstanding concerns raised in the process, to determine whether RAA amendment through this path may still be viable.
The second option for amending the RAA requires Board approval and the voluntary adoption of a revised RAA by registrars. It is anticipated that some forms of incentive would be required to encourage adoption as I previously described.
The third option is the GNSO policy development process that has the ability to modify the terms under which ICANN-accredited registrars do business through the policy development process. In particular, the RAA (at section 4.2: http://www.icann.org/en/registrars/ra-agreement-17may01.htm#4.2) allows for the establishment and revision of policies and specifications in the following areas:
4.2.1 issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, technical reliability, and/or operational stability of Registrar Services, Registry Services, the DNS, or the Internet;
4.2.2 registrar policies reasonably necessary to implement ICANN policies or specifications relating to a DNS registry or to Registry Services;
4.2.3 resolution of disputes concerning the registration of Registered Names (as opposed to the use of such domain names), including where the policies take into account use of the domain names;
4.2.4 principles for allocation of Registered Names (e.g., first-come/first-served, timely renewal, holding period after expiration);
4.2.5 prohibitions on warehousing of or speculation in domain names by registries or registrars;
4.2.6 maintenance of and access to accurate and up-to-date contact information regarding Registered Names and nameservers;
4.2.7 reservation of Registered Names that may not be registered initially or that may not be renewed due to reasons reasonably related to (a) avoidance of confusion among or misleading of users, (b) intellectual property, or (c) the technical management of the DNS or the Internet (e.g., "example.com" and names with single-letter/digit labels);
4.2.8 procedures to avoid disruptions of registration due to suspension or termination of operations by a registry operator or a registrar, including allocation of responsibility among continuing registrars of the Registered Names sponsored in a TLD by a registrar losing accreditation; and
4.2.9 the transfer of registration data upon a change in registrar sponsoring one or more Registered Names.
These topics mark the boundaries of the "picket fence" within which policy development under the current RAA is possible. (A two-thirds GNSO majority would still be required in order for such policies to be enforceable against registrars, as is the case with the RAA amendment process.)
The current set of proposed amendments, reached through community consultation and negotiation with registrars, would reach several areas that are not ordinarily subject to policy development within the picket fence. Please keep in mind that we are not evaluating the specific amendments, just the realm of potential policy development, and also that our analysis may not have taken all factors into account. In other words, the determination of what's inside the picket fence could conceivably result in a different answer under different circumstances.
The following topics that were included in the original package of amendments sent to the GNSO do appear to fall within the picket fence of potential new obligations that could be imposed on registrars via Consensus Policies:
· Escrow of Whois Privacy/Proxy Customer Data
· Registrant Rights and Responsibilities Document
· Registrar Contractual Relationships with Resellers (where the substantive topic lies within the picket fence)
· Disclosure of Registration Licensee Contact Information
· Registrar Disclosure of Its Own Contact Information
· Operator Skills Training & Testing
· Modification of Data Retention Requirements
Based on our initial review, the following topics that were included in the original package of amendments sent to the GNSO appear to fall outside the picket fence, and therefore could not be imposed on registrars via Consensus Policies:
· Registrar Auditing
· Graduated Sanctions & Accreditation Suspension
· Registrar Group Liability
· Registrar Fees
· Registrations by Registrars (the picket fence allows for policy development related to warehousing of domains by registrars, but the topic addressed by the proposed amendment - requiring registrars to comply with all RAA and consensus policy requirements for names registered by the registrar for registrar business use - would not be enforceable as a Consensus Policy under the RAA)
· Modification of Arbitration Rights
· Accreditation by Purchase
· Use of ICANN-Accredited Registrars (is a topic appropriate for policy development by the GNSO, but it would not be enforceable through the RAA as a "Consensus Policy")
· Streamlined Requirements for Registrar Notification of New and Revised Consensus Policies
· Removal of References to U.S. Department of Commerce
It is our expectation that the GNSO will continue to evaluate the need for and undertake policy development within the picket fence that would be applicable to all registrars. Nevertheless, we still see strong value to registrants and the greater Internet community in the proposed amendments, even if they cannot be uniformly applied at this time. In the event a system of incentives is implemented to encourage voluntary adoption by registrars, we will, of course, consult with the GNSO and its member-constituencies as we have throughout this process, to solicit input with regard to the most beneficial and meaningful ways and tools to encourage registrar cooperation.
I hope this information is helpful and clear. I will answer what questions I can and get answers to others.
Regards,
Kurt
Kurt Pritz ICANN
4676 Admiralty Way, Ste. 330 Marina del Rey, CA 90292
+1-310-301-5809 (office) +1-310-400-4184 (mobile)
participants (5)
-
Daniel Halloran -
Kurt Pritz -
Mike Rodenbaugh -
Rosette, Kristina -
Stéphane Van Gelder