Page History

Versions Compared

Key

This line was added.
This line was removed.
Formatting was changed.

Motion 1 on the Adoption of the IRTP Part B Final Report and Recommendations

Made by: Tim Ruiz

Seconded by: Jonathan RobinsonMotion on

Amended by Adrian Kinderis and Kristina Rosette

Motion 1 on the Adoption of the IRTP Part B Final Report and Recommendations

WHEREAS on 24 June 2009, the GNSO Council launched a Policy Development Process (PDP) on IRTP Part B addressing the following five charter questions:

...

WHEREAS the GNSO Council has reviewed and discussed these recommendations.

Approve a PDP Recommendation With a GNSO Supermajority: requires an affirmative vote of a GNSO Supermajority
Approve a PDP Recommendation Without a GNSO Supermajority: requires an affirmative vote of a majority of each House and further requires that one GNSO Council member representative of at least 3 of the 4 Stakeholder Groups supports the Recommendation
Approve a PDP Recommendation With a GNSO Supermajority: requires an affirmative vote of a GNSO Supermajority
Approve a PDP Recommendation Without a GNSO Supermajority: requires an affirmative vote of a majority of each House and further requires that one GNSO Council member representative of at least 3 of the 4 Stakeholder Groups supports the Recommendation

Resolved	Required Voting Threshold [1	https://community.icann.org/#_ftn1]
RESOLVED (A), the GNSO Council recommends to the ICANN Board of Directors: 1. Requiring Registrars to provide a Transfer
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="0ed2c660-2021-4b23-9ed9-2677cc3f63f7"><ac:plain-text-body><![CDATA[	Resolved	Required Voting Threshold [[1]	[https://community.icann.org/#_ftn1] ]	]]></ac:plain-text-body></ac:structured-macro>
RESOLVED (A), the GNSO Council recommends to the ICANN Board of Directors: 1. Requiring Registrars to provide a Transfer Emergency Action Contact (TEAC). To this end the language of section 4 (Registrar Coordination) and Section 6 (Registry Requirements of the Inter-Registrar Transfer Policy should be updated as follows: Transfer Emergency Action Contact (Append to Section 4) Registrars will establish a Transfer Emergency Action Contact (TEAC) for urgent communications relating to transfers. The goal of the TEAC is to quickly establish a real-time conversation between registrars (in a language that both parties can understand) in an emergency. Further actions can then be taken towards a resolution, including initiating existing (or future) transfer dispute or undo processes. Communications to TEACs will be reserved for use by ICANN-Accredited Registrars, gTLD Registry Operators and ICANN Staff. The TEAC point of contact may be designated as a telephone number or some other real-time communication channel and will be recorded in, and protected by, the ICANN RADAR system. Communications to a TEAC must be initiated in a timely manner, within a reasonable period of time following the alleged unauthorized loss of a domain. Messages sent via the TEAC communication channel must generate a non-automated response by a human representative of the gaining Registrar. The person or team responding must be capable and authorized to investigate and address urgent transfer issues. Responses are required within 4 hours of the initial request, although final resolution of the incident may take longer. The losing registrar will report failures to respond to a TEAC communication to ICANN Compliance and the registry operator. Failure to respond to a TEAC communication may result in a transfer-undo in accordance with Section 6 of this policy and may also result in further action by ICANN, up to and including non-renewal or termination of accreditation. Both parties will retain correspondence in written or electronic form of any TEAC communication and responses, and share copies of this documentation with ICANN and the registry operator upon request. This documentation will be retained in accordance with Section 3.4 of the Registrar Accreditation Agreement (RAA). Users of the TEAC communication channel should report non-responsive Registrars to ICANN. Additionally, ICANN may conduct periodic tests of the Registrar TEAC communication channel in situations and a manner deemed appropriate to ensure that registrars are indeed responding to TEAC messages. (Append to Section 6) 6 iv. Documentation provided by the Registrar of Record prior to transfer that the Gaining Registrar has not responded to a message via the TEAC within the timeframe specified in Section 4. In addition, update section 6 to reflect that the registry, in case of a transfer undo, will reverse the transfer and reset the registrar of record filed to its original state (‘In such case, the transfer will be reversed and the Registrar of Record field reset to its original state'). (IRTP Part B Recommendation #1) 2. Modifying section 3 of the IRTP to require that the Registrar of Record/Losing Registrar be required to notify the Registered Name Holder/Registrant of the transfer out. The Registrar of Record has access to the contact information for the Registrant and could modify their systems to automatically send out the Standardized Form for Losing Registrars ("Confirmation FOA") to the Registrant. (IRTP Part B Recommendation #5) 3. Modifying Reason for Denial #6 as follows: Express objection to the transfer by the authorized Transfer Contact. Objection could take the form of specific request (either by paper or electronic means) by the authorized Transfer Contact to deny a particular transfer request, or a general objection to all transfer requests received by the Registrar, either temporarily or indefinitely. In all cases, the objection must be provided with the express and informed consent of the authorized Transfer Contact on an opt-in basis and upon request by the authorized Transfer Contact, the Registrar must remove the lock or provide a reasonably accessible method for the authorized Transfer Contact to remove the lock within five (5) calendar days. (IRTP Part B Recommendation #6) 4. Deleting denial reason #7 as a valid reason for denial under section 3 of the IRTP as it is technically not possible to initiate a transfer for a domain name that is locked, and hence cannot be denied, making this denial reason obsolete. (IRTP Part B Recommendation #9 - part 1)	More than 75% of one House and a majority of the other House ("GNSO Supermajority") <ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="1dce7977-55a8-4c08-9f2e-5ea37b17c69f"><ac:plain-text-body><![CDATA[Approve a PDP Recommendation Imposing New Obligations on Certain Contracting Parties: where an ICANN contract provision specifies that “a two-thirds vote of the council” demonstrates the presence of a consensus, the GNSO Supermajority vote threshold will have to be met or exceeded with respect to any contracting party affected by such contract provision. In the event a GNSO Supermajority Vote is not achieved, approval of the recommendations contained in the Final Report requires a majority of both houses and further requires that one representative of at least 3 of the 4 Stakeholder Groups supports the recommendations. Abstentions shall not be permitted; thus all Council members must cast a vote unless they identify a financial interest in the outcome of the policy issue.[[2]	[https://community.icann.org/#_ftn2] ]	]]></ac:plain-text-body></ac:structured-macro>	RESOLVED (B), the GNSO Council recommends the promotion by ALAC and other ICANN structures of the measures outlined in the recent report of the Security and Stability Advisory Committee on A Registrant's Guide to Protecting Domain Name Registration Accounts (SAC 044). In particular, the GNSO Council recommends that registrants consider the measures to protect domain registrar accounts against compromise and misuse described in SAC044, Section 5. These include practical measures that registrants can implement "in house", such as ways to protect account credentials and how to incorporate domain name registrations into employee or resource management programs typically found in medium and large businesses. It suggests ways that registrants can use renewal and change notifications from registrars as part of an early warning or alerting system for possible account compromise. The GNSO Council Chair will reach out to the ALAC and other ICANN structures to inform them of this recommendation and discuss how the GNSO may contribute to this promotion. (IRTP Part B Recommendation #2)	RESOLVED (C), the GNSO Council recommends that if a review of the UDRP is conducted in the near future, the issue of requiring the locking of a domain name subject to UDRP proceedings is taken into consideration. (IRTP Part B Recommendation #7)

RESOLVED (D), prior to the consideration of approval of the recommendation which states: "denial reason #7 should be replaced by adding a new provision in a different section of the IRTP on when and how domains may be locked or unlocked", the GNSO Council requests ICANN Staff to provide a proposal for such a new provision, taking into account the IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final Report - (Recommendation #9 - part 2). Upon review of the proposal, the GNSO Council will consider whether to approve the recommendation.	Simple majority vote of each House
RESOLVED (E), prior to the consideration of approval of the recommendation regarding the standardizing and clarifying WHOIS status messages regarding Registrar Lock status, the GNSO Council requests ICANN staff to provide a proposal designed to ensure a technically feasible approach can be developed to meet this recommendation. Staff should take into account the IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final Report). (IRTP Part B Recommendation #8). The goal of these changes is to clarify why the Lock has been applied and how it can be changed. Upon review of the proposed plan, the GNSO Council will consider whether to approve the recommendation.	Simple majority vote of each House
RESOLVED (F), the GNSO Council requests an Issues Report on the requirement of ‘thick' WHOIS for all incumbent gTLDs. Such an Issue Report and possible subsequent Policy Development Process should not only consider a possible requirement of 'thick' WHOIS for all incumbent gTLDs in the context of IRTP, but should also consider any other positive and/or negative effects that are likely to occur outside of IRTP that would need to be taken into account when deciding whether a requirement of 'thick' WHOIS for all incumbent gTLDs would be desirable or not. (IRTP Part B Recommendation #3)	At least twenty-five percent (25%) of the members of the Council of each House or a majority of one House.
RESOLVED (G), the GNSO Council requests an Issue Report on IRTP Part C, which should include: - "Change of Control" function, including an investigation of how this function is currently achieved, if there are any applicable models in the country-code name space that can be used as a best practice for the gTLD space, and any associated security concerns. It should also include a review of locking procedures, as described in Reasons for Denial #8 and #9, with an aim to balance legitimate transfer activity and security. (IRTP Part B Recommendation #4) - Whether provisions on time-limiting FOAs should be implemented to avoid fraudulent transfers out. For example, if a Gaining Registrar sends and receives an FOA back from a transfer contact, but the name is locked, the registrar may hold the FOA pending adjustment to the domain name status, during which time the registrant or other registration information may have changed. - Whether the process could be streamlined by a requirement that registries use IANA IDs for registrars rather than proprietary IDs.	At least twenty-five percent (25%) of the members of the Council of each House or a majority of one House.

Wiki Markup
\[[1]\\|https://community.icann.org/#_ftnref1\] As a reminder, the level of support received from the GNSO Council for the recommendation (GNSO Supermajority or no GNSO Supermajority) determines the voting threshold required by the Board to reject a GNSO Council recommendation as outlined in section 13 Board Vote of Annex A of the ICANN Bylaws.

Wiki Markup

\[[1]\|https://community.icann.org/#_ftnref1\] As a reminder, the level of support received from the GNSO Council for the recommendation (GNSO Supermajority or no GNSO Supermajority) determines the voting threshold required by the Board to reject a GNSO Council recommendation as outlined in section 13 Board Vote of Annex A of the ICANN Bylaws.

Wiki Markup
\[[2]\\|https://community.icann.org/#_ftnref2\] In the event that this recommendation is not approved by a GNSO supermajority vote, the recommendations would not be considered consensus policy and therefore not be binding on existing contracted parties. \\

Wiki Markup

\[[2]\|https://community.icann.org/#_ftnref2\] In the event that this recommendation is not approved by a GNSO supermajority vote, the recommendations would not be considered consensus policy and therefore not be binding on existing contracted parties.
\\

MOTION 2. RE. REVISION OF THE GNSO COUNCIL OPERATING PROCEDURES RELATING TO PROXY VOTING

Made by: Wolf-Ulrich Knoben
Seconded by: Stéphane van Gelder

WHEREAS, the GNSO Council recently identified areas for improvement in the GNSO Council Operating Procedures that would simplify and clarify the procedures relating to proxy voting;

WHEREAS, the GNSO Council tasked the Operations Steering Committee (OSC) with completing a revision to improve the procedures relating to proxy voting;

WHEREAS, the OSC submitted to the GNSO Council on 14 June 2011 recommended revisions

http://gnso.icann.org/drafts/osc-recommended-revisions-proxy-voting-14jun11-en.pdf

to the GNSO Council Operating Procedures to simplify and clarify the procedures relating to proxy voting;

NOW THEREFORE, BE IT:

RESOLVED, that the GNSO Council acknowledges receipt of the recommended revisions submitted by the OSC and directs Staff produce a redlined revision of the GNSO Council Operating Procedures incorporating the recommended revisions and to post this document for twenty-one (21) days in the ICANN Public Comment Forum.

Approve a PDP Recommendation Imposing New Obligations on Certain Contracting Parties: where an ICANN contract provision specifies that “a two-thirds vote of the council” demonstrates the presence of a consensus, the GNSO Supermajority vote threshold will have to be met or exceeded with respect to any contracting party affected by such contract provision. In the event a GNSO Supermajority Vote is not achieved, approval of the recommendations contained in the Final Report requires a majority of both houses and further requires that one representative of at least 3 of the 4 Stakeholder Groups supports the recommendations. Abstentions shall not be permitted; thus all Council members must cast a vote unless they identify a financial interest in the outcome of the policy issue.[2

https://community.icann.org/#_ftn2]

RESOLVED (B), the GNSO Council recommends the promotion by ALAC and other ICANN structures of the measures outlined in the recent report of the Security and Stability Advisory Committee on A Registrant's Guide to Protecting Domain Name Registration Accounts (SAC 044). In particular, the GNSO Council recommends that registrants consider the measures to protect domain registrar accounts against compromise and misuse described in SAC044, Section 5. These include practical measures that registrants can implement "in house", such as ways to protect account credentials and how to incorporate domain name registrations into employee or resource management programs typically found in medium and large businesses. It suggests ways that registrants can use renewal and change notifications from registrars as part of an early warning or alerting system for possible account compromise. The GNSO Council Chair will reach out to the ALAC and other ICANN structures to inform them of this recommendation and discuss how the GNSO may contribute to this promotion. (IRTP Part B Recommendation #2)	Approve a PDP Recommendation With a GNSO Supermajority: requires an affirmative vote of a GNSO Supermajority Approve a PDP Recommendation Without a GNSO Supermajority: requires an affirmative vote of a majority of each House and further requires that one GNSO Council member representative of at least 3 of the 4 Stakeholder Groups supports the Recommendation
Resolved (C), the GNSO Council acknowledges receipt of IRTP Part B Recommendation #7 and will consider this recommendation when it considers the Final Issue Report on the Current State of the UDRP.	Simple majority vote of each House
RESOLVED (D), prior to the consideration of approval of the recommendation which states: "denial reason #7 should be replaced by adding a new provision in a different section of the IRTP on when and how domains may be locked or unlocked", the GNSO Council requests ICANN Staff to provide a proposal for such a new provision, taking into account the IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final Report - (Recommendation #9 - part 2). Upon review of the proposal, the GNSO Council will consider whether to approve the recommendation.	Simple majority vote of each House
RESOLVED (E), prior to the consideration of approval of the recommendation regarding the standardizing and clarifying WHOIS status messages regarding Registrar Lock status, the GNSO Council requests ICANN staff to provide a proposal designed to ensure a technically feasible approach can be developed to meet this recommendation. Staff should take into account the IRTP Part B WG deliberations in relation to this issue (see IRTP Part B Final Report). (IRTP Part B Recommendation #8). The goal of these changes is to clarify why the Lock has been applied and how it can be changed. Upon review of the proposed plan, the GNSO Council will consider whether to approve the recommendation.	Simple majority vote of each House
Resolved (F), the GNSO Council will consider IRTP Part B Recommendation #3 concerning the request of an Issue Report on the requirement of 'thick' WHOIS for all incumbent gTLDs at its next meeting on 21 July.	Simple majority vote of each House
RESOLVED (G), the GNSO Council requests an Issue Report on IRTP Part C, which should include: - "Change of Control" function, including an investigation of how this function is currently achieved, if there are any applicable models in the country-code name space that can be used as a best practice for the gTLD space, and any associated security concerns. It should also include a review of locking procedures, as described in Reasons for Denial #8 and #9, with an aim to balance legitimate transfer activity and security. (IRTP Part B Recommendation #4) - Whether provisions on time-limiting FOAs should be implemented to avoid fraudulent transfers out. For example, if a Gaining Registrar sends and receives an FOA back from a transfer contact, but the name is locked, the registrar may hold the FOA pending adjustment to the domain name status, during which time the registrant or other registration information may have changed. - Whether the process could be streamlined by a requirement that registries use IANA IDs for registrars rather than proprietary IDs.	At least twenty-five percent (25%) of the members of the Council of each House or a majority of one House.

...

[1|https://community.icann.org/#_ftnref1] As a reminder, the level of support received from the GNSO Council for the recommendation (GNSO Supermajority or no GNSO Supermajority) determines the voting threshold required by the Board to reject a GNSO Council recommendation as outlined in section 13 Board Vote of Annex A of the ICANN Bylaws.

[2|https://community.icann.org/#_ftnref2] In the event that this recommendation is not approved by a GNSO supermajority vote, the recommendations would not be considered consensus policy and therefore not be binding on existing contracted parties.

MOTION 2. RE. REVISION OF THE GNSO COUNCIL OPERATING PROCEDURES RELATING TO PROXY VOTING

Made by: Wolf-Ulrich Knoben
Seconded by: Stéphane van Gelder

WHEREAS, the GNSO Council recently identified areas for improvement in the GNSO Council Operating Procedures that would simplify and clarify the procedures relating to proxy voting;

WHEREAS, the GNSO Council tasked the Operations Steering Committee (OSC) with completing a revision to improve the procedures relating to proxy voting;

WHEREAS, the OSC submitted to the GNSO Council on 14 June 2011 recommended revisions

http://gnso.icann.org/drafts/osc-recommended-revisions-proxy-voting-14jun11-en.pdf

to the GNSO Council Operating Procedures to simplify and clarify the procedures relating to proxy voting;

NOW THEREFORE, BE IT:

RESOLVED FURTHER, that the GNSO Council shall take formal action on these recommendations, including potential modification, as soon as possible after the conclusion of the public comment period.

Motion 3 on the Adoption of the PEDNR Final Report and Recommendations - For discussion only

Whereas on 7 May 2009, the GNSO Council launched a Policy Development Process (PDP) on Post-Expiration Domain Name Recovery (PEDNR) addressing the following five charter questions:

1. Whether adequate opportunity exists for registrants to redeem their expired domain names;

2. Whether expiration-related provisions in typical registration agreements are clear and conspicuous enough;

3. Whether adequate notice exists to alert registrants of upcoming expirations;

4. Whether additional measures need to be implemented to indicate that once a domain name enters the Auto-Renew Grace Period, it has expired (e.g., hold

status, a notice on the site with a link to information on how to renew, or other options to be determined);

5. Whether to allow the transfer of a domain name during the RGP.

Whereas this PDP has followed the prescribed PDP steps as stated in the ICANN Bylaws, resulting in a Final Report delivered on 14 June 2011;

Whereas the PEDNR WG has reached full consensus on the recommendations in relation to each of the five issues outlined above;

Whereas the PEDNR WG considers all the recommendations listed below as interdependent and has recommended that the GNSO Council should consider these recommendations as such;

Whereas the GNSO Council has reviewed and discussed these recommendations.

RESOLVED, the GNSO Council recommends to the ICANN Board of Directors:

(A):

1. Define “Registered Name Holder at Expiration” (RNHaE) as the entity or individual that was eligible to renew the domain name registration immediately prior to expiration. If the domain name registration was modified pursuant to a term of the Registration Agreement authorizing the modification of registration data for the

purposes of facilitating renewal but not at the explicit request of the registrant, the RNHaE is the entity or individual identified as the registrant immediately prior to that modification. (PEDNR Recommendation #1)

2. For at least 8 consecutive days, at some point following expiration, the original DNS resolution path specified by the RNHaE, at the time of expiration, must be

interrupted1 by the registrar, to the extent that the registry permits such interruptions, and the domain must be renewable by the RNHaE until the end of that period. This 8-day period may occur at any time following expiration. At any time during the 8 day period, the Registered Name Holder at Expiration may renew the domain with the Registrar and the Registrar, within a commercially reasonable delay, will restore the domain name to resolve to its original DNS resolution path prior to expiration. Notwithstanding, the Registrar may delete the domain at any time during the Autorenew grace period. (PEDNR Recommendation #2)

3. If at any time after expiration when the Registered Name is still renewable by the RNHaE, the Registrar changes the DNS resolution path to effect a different landing website than the one used by the RNHaE prior to expiration, the page shown must explicitly say that the domain has expired and give instructions on how to recover the domain. Wording in the policy must make clear that “instructions” may be as simple as directing the RNHaE to a specific web site. (PEDNR Recommendation #3)

4. The RNHaE cannot be prevented from renewing a domain name registration as a result of WHOIS changes made by the Registrar that were not at the RNHaE’s

request. (PEDNR Recommendation #4)

5. The registration agreement must include or point to any fee(s) charged for the postexpiration renewal of a domain name. If the Registrar operates a website for

registration or renewal, it should state, both at the time of registration and in a clear place on its website, any fee(s) charged for the post-expiration renewal of a domain name or the recovery of a domain name during the Redemption Grace Period. (PEDNR Recommendation #5)

1 DNS interruption is defined as total Internet service interruption except for an informational web page (only one IP on which only port 80 is active).

6. The registration agreement and Registrar web site (if one is used) must clearly indicate what methods will be used to deliver pre- and post-expiration notifications, or must point to the location where such information can be found. What destination address/number will be used must also be specified, if applicable. (PEDNR Recommendation #6)

7. Registrar must notify Registered Name Holder of impending expiration no less than two times. One such notice must be sent one month or 30 days prior to expiration (±4 days) and one must be sent one week prior to expiration (±3 days). If more that two alert notifications are sent, the timing of two of them must be comparable to the timings specified. (PEDNR Recommendation #7)

8. Unless the Registered Name is renewed or deleted by the Registrar, at least one notification to the RNHaE, which includes renewal instructions, must be sent after expiration. (PEDNR Recommendation #8)

9. Notifications of impending expiration must include method(s) that do not require explicit registrant action other than standard e-mail receipt in order to receive such notifications. (Recommendation #9)

10. With the exception of sponsored2 gTLDs, all gTLD Registries shall offer the Redemption Grace Period (RGP). For currently existing unsponsored gTLDs that do not currently offer the RGP, a transition period shall be allowed. All new gTLDs must offer the RGP. As part of the implementation, ICANN Staff should consider the Technical Steering Group's Implementation Proposal (see http://www.icann.org/en/ meetings/bucharest/redemption-topic.htm) (PEDNR Recommendation #13)

11. If a Registrar offers registrations in a gTLD that supports the RGP, the Registrar must allow the Registered Name Holder at Expiration to redeem the Registered Name after it has entered RGP. (PEDNR Recommendation #14)

12. A transfer of a domain name during the RGP should not be allowed. (PEDNR Recommendation #15)

13. In the event that ICANN gives reasonable notice to Registrars that ICANN has published web content as described in PEDNR Recommendation #16:

§ Registrars, who have a web presence, must provide a link to the ICANN content on any website it may operate for domain name registration or renewal clearly

displayed to its Registered Name Holders at least as clearly as its links to policies or notifications required to be displayed under ICANN Consensus Policies.

§ Registrars may also host similar material adapted to their specific practices and processes.

§ Registrar must point to the ICANN material in a communication sent to the registrant immediately following initial registration as well as in the mandated

annual WHOIS reminder.

(PEDNR Recommendation #17)

Note: Some of these recommendations may need special consideration in the context of existing provisions in the Uniform Dispute Resolution Policy (UDRP), the proposed Uniform Rapid Suspension System (URS) or exceptions due to fraud, breach of registration agreement or other substantive reasons and the GNSO Council, therefore, recommends that such considerations are taken into account as part of the implementation of these recommendations, once adopted.

(B) The GNSO Council recommends the following best practices for promotion by ICANN and the Registrar Stakeholder Group:

• If post-expiration notifications are normally sent to a point of contact using the domain in question, and delivery is known to have been interrupted by postexpiration actions, post-expiration notifications should be sent to some other contact point associated with the registrant if one exists. (PEDNR

Recommendation #10)

• The notification method explanation (see recommendation #9) should include the registrar’s email address from which notification messages are sent and a

suggestion that registrants save this email address as a ‘safe sender’ to avoid notification emails being blocked by spam filter software. (PEDNR

Recommendation #11)

• Registrars should advise registrants to provide a secondary email point of contact that is not associated with the domain name itself so that in case of

expiration reminders can be delivered to this secondary email point of contact. (PEDNR Recommendation #12)

(C) The GNSO Council recommends that ICANN, in consultation with Registrars, ALAC and other interested parties, will develop educational materials about how to properly steward a domain name and how to prevent unintended loss. Such material may include registrant responsibilities and the gTLD domain life-cycle and guidelines for keeping domain name records current. (PEDNR Recommendation #16).

(D) ICANN Compliance is requested to provide updates to the GNSO Council on a regular basis in relation to the implementation and effectiveness of the proposed recommendations, either in the form of a report that details amongst others the number of complaints received in relation to renewal and/or post-expiration related matters or in the form of audits that assess if the policy has been implemented as intended. (PEDNR Recommendation #18)

Footnotes:

1 DNS interruption is defined as total Internet service interruption except for an informational web page (only one IP on which only port 80 is active).

2 An unsponsored TLD operates under policies established by the global Internet community directly through the ICANN process, while a sponsored TLD is a specialized TLD that has a

sponsor representing the narrower community that is most affected by the TLD. It should be noted that this distinction is no longer used in the new gTLD programRESOLVED FURTHER, that the GNSO Council shall take formal action on these recommendations, including potential modification, as soon as possible after the conclusion of the public comment period.

Content

Space Tools

Versions Compared

Old Version 13

New Version 14

Key

Motion 1 on the Adoption of the IRTP Part B Final Report and Recommendations