Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration
Dear IRT members, As you know, on 7 February 2014, the ICANN Board adopted GNSO consensus policy recommendations regarding the provision of “Thick” Whois by all gTLD registries. In consultation with the consensus policy Implementation Review Team (IRT), the implementation team identified two expected outcomes in the policy development process (PDP) recommendations: * The consistent labeling and display of WHOIS output for all gTLDs * The transition from Thin to Thick WHOIS for .COM, .NET and .JOBS The first outcome was published as a consensus policy, the Registry Registration Data Directory Services Consistent Labeling and Display Policy<https://www.icann.org/resources/pages/rdds-labeling-policy-2016-07-26-en> (CL&D Policy), on 26 July 2016. In August 2016, the Registry Stakeholder Group (RySG) submitted a Request for Reconsideration<https://www.icann.org/resources/pages/reconsideration-16-10-rysg-request-201...> (RfR) regarding the CL&D Policy. The RfR objects to the inclusion of RDAP as part of the Consensus Policy as RDAP was not contemplated or referenced in the policy recommendations. To resolve this matter, ICANN proposes the following path forward for the IRT: 1. ICANN to issue a revised CL&D Policy to all registry operators, removing provision 12. For your reference, provision 12 states: “The implementation of an RDAP service in accordance with the "RDAP Operational Profile for gTLD Registries and Registrars<https://www.icann.org/rdap-gtld-profile>" is required for all gTLD registries in order to achieve consistent labeling and display.” Additionally, I have attached the proposed revised CL&D Policy. 2. Issue a revised notification to registry operators regarding implementation of the CL&D Policy, clearly indicating what has changed in the revised CL&D Policy. 3. Set the revised CL&D Policy effective date to allow for full 6-month implementation from the date of the revised notice. 4. Update the published CL&D Policy on the ICANN website, noting a change has been made. Note: The revised CL&D Policy would not be subject to another Public Comment process. 5. Rescind the notification sent to registrars to implement RDAP. ICANN intends to issue notices for registries and registrars to implement RDAP after further dialogue with the community. Please let us know if you have comments or concerns by responding to this list. Unless we hear otherwise, we intend to move forward with the plan outlined above on 4 October 2016. — Kind Regards, Dennis S. Chang GDD Services & Engagement Program Director +1 213 293 7889 Skype: dennisSchang www.icann.org "One World, One Internet"
Dennis, Thank you for the excellent explanation and details. On behalf of Verisign and as a member of the RySG I would like to express my support for the revised CL&D policy and the path forward you have laid out. Thank you, Marc Anderson From: gnso-impl-thickwhois-rt-bounces@icann.org [mailto:gnso-impl-thickwhois-rt-bounces@icann.org] On Behalf Of Dennis Chang Sent: Wednesday, September 21, 2016 1:42 PM To: gnso-impl-thickwhois-rt@icann.org Subject: [Gnso-impl-thickwhois-rt] Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration Dear IRT members, As you know, on 7 February 2014, the ICANN Board adopted GNSO consensus policy recommendations regarding the provision of “Thick” Whois by all gTLD registries. In consultation with the consensus policy Implementation Review Team (IRT), the implementation team identified two expected outcomes in the policy development process (PDP) recommendations: * The consistent labeling and display of WHOIS output for all gTLDs * The transition from Thin to Thick WHOIS for .COM, .NET and .JOBS The first outcome was published as a consensus policy, the Registry Registration Data Directory Services Consistent Labeling and Display Policy<https://www.icann.org/resources/pages/rdds-labeling-policy-2016-07-26-en> (CL&D Policy), on 26 July 2016. In August 2016, the Registry Stakeholder Group (RySG) submitted a Request for Reconsideration<https://www.icann.org/resources/pages/reconsideration-16-10-rysg-request-201...> (RfR) regarding the CL&D Policy. The RfR objects to the inclusion of RDAP as part of the Consensus Policy as RDAP was not contemplated or referenced in the policy recommendations. To resolve this matter, ICANN proposes the following path forward for the IRT: 1. ICANN to issue a revised CL&D Policy to all registry operators, removing provision 12. For your reference, provision 12 states: “The implementation of an RDAP service in accordance with the "RDAP Operational Profile for gTLD Registries and Registrars<https://www.icann.org/rdap-gtld-profile>" is required for all gTLD registries in order to achieve consistent labeling and display.” Additionally, I have attached the proposed revised CL&D Policy. 2. Issue a revised notification to registry operators regarding implementation of the CL&D Policy, clearly indicating what has changed in the revised CL&D Policy. 3. Set the revised CL&D Policy effective date to allow for full 6-month implementation from the date of the revised notice. 4. Update the published CL&D Policy on the ICANN website, noting a change has been made. Note: The revised CL&D Policy would not be subject to another Public Comment process. 5. Rescind the notification sent to registrars to implement RDAP. ICANN intends to issue notices for registries and registrars to implement RDAP after further dialogue with the community. Please let us know if you have comments or concerns by responding to this list. Unless we hear otherwise, we intend to move forward with the plan outlined above on 4 October 2016. — Kind Regards, Dennis S. Chang GDD Services & Engagement Program Director +1 213 293 7889 Skype: dennisSchang www.icann.org<http://www.icann.org> "One World, One Internet"
Dennis, This looks like the path forward, and I am supportive of the proposed path forward as a Registrar. Perhaps I am jumping the gun here, but how would this dialogue with the community take place? Furthermore, how do we address irregularities within RDAP? Or get clarification on a few issues that I assume have not been discussed yet? Thanks, Theo On 21-9-2016 19:58, Anderson, Marc wrote:
Dennis,
Thank you for the excellent explanation and details. On behalf of Verisign and as a member of the RySG I would like to express my support for the revised CL&D policy and the path forward you have laid out.
Thank you,
Marc Anderson
*From:*gnso-impl-thickwhois-rt-bounces@icann.org [mailto:gnso-impl-thickwhois-rt-bounces@icann.org] *On Behalf Of *Dennis Chang *Sent:* Wednesday, September 21, 2016 1:42 PM *To:* gnso-impl-thickwhois-rt@icann.org *Subject:* [Gnso-impl-thickwhois-rt] Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration
Dear IRT members,
As you know, on 7 February 2014, the ICANN Board adopted GNSO consensus policy recommendations regarding the provision of “Thick” Whois by all gTLD registries.
In consultation with the consensus policy Implementation Review Team (IRT), the implementation team identified two expected outcomes in the policy development process (PDP) recommendations:
* The consistent labeling and display of WHOIS output for all gTLDs * The transition from Thin to Thick WHOIS for .COM, .NET and .JOBS
The first outcome was published as a consensus policy, the Registry Registration Data Directory Services Consistent Labeling and Display Policy <https://www.icann.org/resources/pages/rdds-labeling-policy-2016-07-26-en> (CL&D Policy), on 26 July 2016.
In August 2016, the Registry Stakeholder Group (RySG) submitted a Request for Reconsideration <https://www.icann.org/resources/pages/reconsideration-16-10-rysg-request-201...> (RfR) regarding the CL&D Policy. The RfR objects to the inclusion of RDAP as part of the Consensus Policy as RDAP was not contemplated or referenced in the policy recommendations.
To resolve this matter, ICANN proposes the following path forward for the IRT:
1. ICANN to issue a revised CL&D Policy to all registry operators, removing provision 12. For your reference, provision 12 states: “The implementation of an RDAP service in accordance with the "RDAP Operational Profile for gTLD Registries and Registrars <https://www.icann.org/rdap-gtld-profile>" is required for all gTLD registries in order to achieve consistent labeling and display.” Additionally, I have attached the proposed revised CL&D Policy.
2. Issue a revised notification to registry operators regarding implementation of the CL&D Policy, clearly indicating what has changed in the revised CL&D Policy.
3. Set the revised CL&D Policy effective date to allow for full 6-month implementation from the date of the revised notice.
4. Update the published CL&D Policy on the ICANN website, noting a change has been made. Note: The revised CL&D Policy would _not_ be subject to another Public Comment process.
5. Rescind the notification sent to registrars to implement RDAP.
ICANN intends to issue notices for registries and registrars to implement RDAP after further dialogue with the community.
Please let us know if you have comments or concerns by responding to this list. Unless we hear otherwise, we intend to move forward with the plan outlined above on 4 October 2016.
—
Kind Regards,
Dennis S. Chang
GDD Services & Engagement Program Director
+1 213 293 7889
Skype: dennisSchang
www.icann.org <http://www.icann.org> "One World, One Internet"
_______________________________________________ Gnso-impl-thickwhois-rt mailing list Gnso-impl-thickwhois-rt@icann.org https://mm.icann.org/mailman/listinfo/gnso-impl-thickwhois-rt
Hi Theo, This is the first item on the agenda for the IRT meeting on Tuesday. Please keep the questions coming. If you could provide specifics on “irregularities within RDAP” and “clarification on a few issues” in advance, that will help us to prepare better for our team discussion. Thanks Dennis Chang From: theo geurts <gtheo@xs4all.nl> Date: Thursday, September 22, 2016 at 1:16 AM To: "Anderson, Marc" <mcanderson@verisign.com>, Dennis Chang <dennis.chang@icann.org>, "gnso-impl-thickwhois-rt@icann.org" <gnso-impl-thickwhois-rt@icann.org> Subject: Re: [Gnso-impl-thickwhois-rt] Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration Dennis, This looks like the path forward, and I am supportive of the proposed path forward as a Registrar. Perhaps I am jumping the gun here, but how would this dialogue with the community take place? Furthermore, how do we address irregularities within RDAP? Or get clarification on a few issues that I assume have not been discussed yet? Thanks, Theo On 21-9-2016 19:58, Anderson, Marc wrote: Dennis, Thank you for the excellent explanation and details. On behalf of Verisign and as a member of the RySG I would like to express my support for the revised CL&D policy and the path forward you have laid out. Thank you, Marc Anderson From: gnso-impl-thickwhois-rt-bounces@icann.org<mailto:gnso-impl-thickwhois-rt-bounces@icann.org> [mailto:gnso-impl-thickwhois-rt-bounces@icann.org] On Behalf Of Dennis Chang Sent: Wednesday, September 21, 2016 1:42 PM To: gnso-impl-thickwhois-rt@icann.org<mailto:gnso-impl-thickwhois-rt@icann.org> Subject: [Gnso-impl-thickwhois-rt] Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration Dear IRT members, As you know, on 7 February 2014, the ICANN Board adopted GNSO consensus policy recommendations regarding the provision of “Thick” Whois by all gTLD registries. In consultation with the consensus policy Implementation Review Team (IRT), the implementation team identified two expected outcomes in the policy development process (PDP) recommendations: * The consistent labeling and display of WHOIS output for all gTLDs * The transition from Thin to Thick WHOIS for .COM, .NET and .JOBS The first outcome was published as a consensus policy, the Registry Registration Data Directory Services Consistent Labeling and Display Policy[icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources...> (CL&D Policy), on 26 July 2016. In August 2016, the Registry Stakeholder Group (RySG) submitted a Request for Reconsideration[icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources...> (RfR) regarding the CL&D Policy. The RfR objects to the inclusion of RDAP as part of the Consensus Policy as RDAP was not contemplated or referenced in the policy recommendations. To resolve this matter, ICANN proposes the following path forward for the IRT: 1. ICANN to issue a revised CL&D Policy to all registry operators, removing provision 12. For your reference, provision 12 states: “The implementation of an RDAP service in accordance with the "RDAP Operational Profile for gTLD Registries and Registrars[icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_rdap-2Dgt...>" is required for all gTLD registries in order to achieve consistent labeling and display.” Additionally, I have attached the proposed revised CL&D Policy. 2. Issue a revised notification to registry operators regarding implementation of the CL&D Policy, clearly indicating what has changed in the revised CL&D Policy. 3. Set the revised CL&D Policy effective date to allow for full 6-month implementation from the date of the revised notice. 4. Update the published CL&D Policy on the ICANN website, noting a change has been made. Note: The revised CL&D Policy would not be subject to another Public Comment process. 5. Rescind the notification sent to registrars to implement RDAP. ICANN intends to issue notices for registries and registrars to implement RDAP after further dialogue with the community. Please let us know if you have comments or concerns by responding to this list. Unless we hear otherwise, we intend to move forward with the plan outlined above on 4 October 2016. — Kind Regards, Dennis S. Chang GDD Services & Engagement Program Director +1 213 293 7889 Skype: dennisSchang www.icann.org[icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.icann.org&d=DQMDaQ&c...> "One World, One Internet" _______________________________________________ Gnso-impl-thickwhois-rt mailing list Gnso-impl-thickwhois-rt@icann.org<mailto:Gnso-impl-thickwhois-rt@icann.org> https://mm.icann.org/mailman/listinfo/gnso-impl-thickwhois-rt[mm.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Dimpl-2Dthickwhois-2Drt&d=DQMDaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=dqLP1wJqBvDSYLKrSEaAkCi_Kv0Mk5D_d32n29DHCN8&m=pkBrE3ogDYFgpWAATzOOdmRD93_Pz1PCrWtnSZN7Lg4&s=4kbspuXnx6QwVFowMkdtINMgbQE8VDBSKEyWHfD8wDo&e=>
Thanks Dennis, First of all, if we look what has been published is that RDAP should be implemented Feb 1, 2017 (draft 1 April). What I am missing, is a transition period. If everyone implements it, and shuts down the WHOIS servers we have a problem. The resource records related to the RDAP service MUST be signed with DNSSEC, and the DNSSEC chain of trust from the root trust anchor to the name of the RDAP server MUST be valid at all times. -Looks sensible, but I cannot find this in the RFC's mentioned, is the above language a result of this? In the case (i.e. uppercase and lowercase) of the data returned in RDAP responses SHOULD preserve the case received via EPP. -TG- This needs to be specified perhaps for contact fields for example. As it, reads now you register ExAmPlE.com but you cannot return, example.com. Least that is how I read it. The domain object in the RDAP response MUST contain entities with the following roles. Exactly one entity per role MUST be present in the response. -TG-Most gTLDs support more roles. Is there no support or does the policy ends this support for more roles? -RDAP does not support a country code for a contact, rather RDAP requires a full country name. -TG- This, is a mapping nightmare, not everyone supports the official mapping, not sure how much work this is and will vary from Registrar to Registrar. If the queried domain name is allocated, the following applies: If allocated variant domain names exist for the queried domain name, or if the domain name is an allocated variant domain name, the domain object in the RDAP response MUST contain a variants member [RFC7483]. -TG- We do not store this, and it seems to contradict the following in the profile :"The purpose of this profile is to specify the RDAP requirements that are in line with the current Whois service requirements." Best regards, Theo On 24-9-2016 20:10, Dennis Chang wrote:
Hi Theo,
This is the first item on the agenda for the IRT meeting on Tuesday.
Please keep the questions coming.
If you could provide specifics on “irregularities within RDAP” and “clarification on a few issues” in advance, that will help us to prepare better for our team discussion.
Thanks
Dennis Chang
*From: *theo geurts <gtheo@xs4all.nl> *Date: *Thursday, September 22, 2016 at 1:16 AM *To: *"Anderson, Marc" <mcanderson@verisign.com>, Dennis Chang <dennis.chang@icann.org>, "gnso-impl-thickwhois-rt@icann.org" <gnso-impl-thickwhois-rt@icann.org> *Subject: *Re: [Gnso-impl-thickwhois-rt] Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration
Dennis,
This looks like the path forward, and I am supportive of the proposed path forward as a Registrar.
Perhaps I am jumping the gun here, but how would this dialogue with the community take place? Furthermore, how do we address irregularities within RDAP? Or get clarification on a few issues that I assume have not been discussed yet?
Thanks,
Theo
On 21-9-2016 19:58, Anderson, Marc wrote:
Dennis,
Thank you for the excellent explanation and details. On behalf of Verisign and as a member of the RySG I would like to express my support for the revised CL&D policy and the path forward you have laid out.
Thank you,
Marc Anderson
*From:*gnso-impl-thickwhois-rt-bounces@icann.org <mailto:gnso-impl-thickwhois-rt-bounces@icann.org> [mailto:gnso-impl-thickwhois-rt-bounces@icann.org] *On Behalf Of *Dennis Chang *Sent:* Wednesday, September 21, 2016 1:42 PM *To:* gnso-impl-thickwhois-rt@icann.org <mailto:gnso-impl-thickwhois-rt@icann.org> *Subject:* [Gnso-impl-thickwhois-rt] Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration
Dear IRT members,
As you know, on 7 February 2014, the ICANN Board adopted GNSO consensus policy recommendations regarding the provision of “Thick” Whois by all gTLD registries.
In consultation with the consensus policy Implementation Review Team (IRT), the implementation team identified two expected outcomes in the policy development process (PDP) recommendations:
* The consistent labeling and display of WHOIS output for all gTLDs * The transition from Thin to Thick WHOIS for .COM, .NET and .JOBS
The first outcome was published as a consensus policy, the Registry Registration Data Directory Services Consistent Labeling and Display Policy[icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources...> (CL&D Policy), on 26 July 2016.
In August 2016, the Registry Stakeholder Group (RySG) submitted a Request for Reconsideration[icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources...> (RfR) regarding the CL&D Policy. The RfR objects to the inclusion of RDAP as part of the Consensus Policy as RDAP was not contemplated or referenced in the policy recommendations.
To resolve this matter, ICANN proposes the following path forward for the IRT:
1. ICANN to issue a revised CL&D Policy to all registry operators, removing provision 12. For your reference, provision 12 states: “The implementation of an RDAP service in accordance with the "RDAP Operational Profile for gTLD Registries and Registrars[icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_rdap-2Dgt...>" is required for all gTLD registries in order to achieve consistent labeling and display.” Additionally, I have attached the proposed revised CL&D Policy.
2. Issue a revised notification to registry operators regarding implementation of the CL&D Policy, clearly indicating what has changed in the revised CL&D Policy.
3. Set the revised CL&D Policy effective date to allow for full 6-month implementation from the date of the revised notice.
4. Update the published CL&D Policy on the ICANN website, noting a change has been made. Note: The revised CL&D Policy would _not_ be subject to another Public Comment process.
5. Rescind the notification sent to registrars to implement RDAP.
ICANN intends to issue notices for registries and registrars to implement RDAP after further dialogue with the community.
Please let us know if you have comments or concerns by responding to this list. Unless we hear otherwise, we intend to move forward with the plan outlined above on 4 October 2016.
—
Kind Regards,
Dennis S. Chang
GDD Services & Engagement Program Director
+1 213 293 7889
Skype: dennisSchang
www.icann.org[icann.org] <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.icann.org&d=DQMDaQ&c...> "One World, One Internet"
_______________________________________________
Gnso-impl-thickwhois-rt mailing list
Gnso-impl-thickwhois-rt@icann.org <mailto:Gnso-impl-thickwhois-rt@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-impl-thickwhois-rt[mm.icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...>
The resource records related to the RDAP service MUST be signed with DNSSEC, and the DNSSEC chain of trust from the root trust anchor to the name of the RDAP server MUST be valid at all times. -Looks sensible, but I cannot find this in the RFC's mentioned, is the above language a result of this?
Another case of "nice to have, so let's add it!"?
The domain object in the RDAP response MUST contain entities with the following roles. Exactly one entity per role MUST be present in the response. -TG-Most gTLDs support more roles. Is there no support or does the policy ends this support for more roles?
Better require a minimum of one entity per role to remain consistent.
-RDAP does not support a country code for a contact, rather RDAP requires a full country name. -TG- This, is a mapping nightmare, not everyone supports the official mapping, not sure how much work this is and will vary from Registrar to Registrar.
RDAP requires full countryname in what language? Should we for example put Deutschland, Duitsland, Germany, Allemangne, 德国 (Dégúo), Tyskland, ma Tosi, Đức, 독일 (Dogil), ドイツ (Doitsu), or all of the above and more? Keeping the country code makes sense, replacing it does not. Common sense should prevail over non-sense, or nonsense!
If the queried domain name is allocated, the following applies: If allocated variant domain names exist for the queried domain name, or if the domain name is an allocated variant domain name, the domain object in the RDAP response MUST contain a variants member [RFC7483]. -TG- We do not store this, and it seems to contradict the following in the profile :"The purpose of this profile is to specify the RDAP requirements that are in line with the current Whois service requirements."
+1 Best regards, Volker
On 24-9-2016 20:10, Dennis Chang wrote:
Hi Theo,
This is the first item on the agenda for the IRT meeting on Tuesday.
Please keep the questions coming.
If you could provide specifics on “irregularities within RDAP” and “clarification on a few issues” in advance, that will help us to prepare better for our team discussion.
Thanks
Dennis Chang
*From: *theo geurts <gtheo@xs4all.nl> *Date: *Thursday, September 22, 2016 at 1:16 AM *To: *"Anderson, Marc" <mcanderson@verisign.com>, Dennis Chang <dennis.chang@icann.org>, "gnso-impl-thickwhois-rt@icann.org" <gnso-impl-thickwhois-rt@icann.org> *Subject: *Re: [Gnso-impl-thickwhois-rt] Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration
Dennis,
This looks like the path forward, and I am supportive of the proposed path forward as a Registrar.
Perhaps I am jumping the gun here, but how would this dialogue with the community take place? Furthermore, how do we address irregularities within RDAP? Or get clarification on a few issues that I assume have not been discussed yet?
Thanks,
Theo
On 21-9-2016 19:58, Anderson, Marc wrote:
Dennis,
Thank you for the excellent explanation and details. On behalf of Verisign and as a member of the RySG I would like to express my support for the revised CL&D policy and the path forward you have laid out.
Thank you,
Marc Anderson
*From:*gnso-impl-thickwhois-rt-bounces@icann.org <mailto:gnso-impl-thickwhois-rt-bounces@icann.org> [mailto:gnso-impl-thickwhois-rt-bounces@icann.org] *On Behalf Of *Dennis Chang *Sent:* Wednesday, September 21, 2016 1:42 PM *To:* gnso-impl-thickwhois-rt@icann.org <mailto:gnso-impl-thickwhois-rt@icann.org> *Subject:* [Gnso-impl-thickwhois-rt] Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration
Dear IRT members,
As you know, on 7 February 2014, the ICANN Board adopted GNSO consensus policy recommendations regarding the provision of “Thick” Whois by all gTLD registries.
In consultation with the consensus policy Implementation Review Team (IRT), the implementation team identified two expected outcomes in the policy development process (PDP) recommendations:
* The consistent labeling and display of WHOIS output for all gTLDs * The transition from Thin to Thick WHOIS for .COM, .NET and .JOBS
The first outcome was published as a consensus policy, the Registry Registration Data Directory Services Consistent Labeling and Display Policy[icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources...> (CL&D Policy), on 26 July 2016.
In August 2016, the Registry Stakeholder Group (RySG) submitted a Request for Reconsideration[icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources...> (RfR) regarding the CL&D Policy. The RfR objects to the inclusion of RDAP as part of the Consensus Policy as RDAP was not contemplated or referenced in the policy recommendations.
To resolve this matter, ICANN proposes the following path forward for the IRT:
1. ICANN to issue a revised CL&D Policy to all registry operators, removing provision 12. For your reference, provision 12 states: “The implementation of an RDAP service in accordance with the "RDAP Operational Profile for gTLD Registries and Registrars[icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_rdap-2Dgt...>" is required for all gTLD registries in order to achieve consistent labeling and display.” Additionally, I have attached the proposed revised CL&D Policy.
2. Issue a revised notification to registry operators regarding implementation of the CL&D Policy, clearly indicating what has changed in the revised CL&D Policy.
3. Set the revised CL&D Policy effective date to allow for full 6-month implementation from the date of the revised notice.
4. Update the published CL&D Policy on the ICANN website, noting a change has been made. Note: The revised CL&D Policy would _not_ be subject to another Public Comment process.
5. Rescind the notification sent to registrars to implement RDAP.
ICANN intends to issue notices for registries and registrars to implement RDAP after further dialogue with the community.
Please let us know if you have comments or concerns by responding to this list. Unless we hear otherwise, we intend to move forward with the plan outlined above on 4 October 2016.
—
Kind Regards,
Dennis S. Chang
GDD Services & Engagement Program Director
+1 213 293 7889
Skype: dennisSchang
www.icann.org[icann.org] <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.icann.org&d=DQMDaQ&c...> "One World, One Internet"
_______________________________________________
Gnso-impl-thickwhois-rt mailing list
Gnso-impl-thickwhois-rt@icann.org <mailto:Gnso-impl-thickwhois-rt@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-impl-thickwhois-rt[mm.icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...>
_______________________________________________ Gnso-impl-thickwhois-rt mailing list Gnso-impl-thickwhois-rt@icann.org https://mm.icann.org/mailman/listinfo/gnso-impl-thickwhois-rt
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
[Apologies for not replying inline, the new version of Outlook won’t let me.] The date for shutting down Whois port 43 has not been discussed or defined with the community. Therefore, stating 1 February 2017 we would be in the transition period where both WHOIS and RDAP would coexist. The requirement for having a valid DNSSEC chain of trust is not coming from the RDAP RFCs; this is a requirement from the gTLD RDAP profile that was discussed and agreed with the community. The requirement to preserve case is a “SHOULD” not a “MUST”, hence following your example, the contracted party would be free to return “example.com”. The gTLD RDAP profile requires registrant, technical and administrative, and optionally allows for a billing contact. The gTLD profile addresses how to support more roles (e.g., contacts), for example, see section 1.3.6 of the profile. Regarding variants, section 1.5.17 of the profile addresses this: In the case of Registrars, the variants member MUST reflect the latest known set of variant domain names and relation types. Regards, -- Francisco On 9/26/16, 5:05 AM, "gnso-impl-thickwhois-rt-bounces@icann.org<mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of theo geurts" <gnso-impl-thickwhois-rt-bounces@icann.org<mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of gtheo@xs4all.nl<mailto:gtheo@xs4all.nl>> wrote: Thanks Dennis, First of all, if we look what has been published is that RDAP should be implemented Feb 1, 2017 (draft 1 April). What I am missing, is a transition period. If everyone implements it, and shuts down the WHOIS servers we have a problem. The resource records related to the RDAP service MUST be signed with DNSSEC, and the DNSSEC chain of trust from the root trust anchor to the name of the RDAP server MUST be valid at all times. -Looks sensible, but I cannot find this in the RFC's mentioned, is the above language a result of this? In the case (i.e. uppercase and lowercase) of the data returned in RDAP responses SHOULD preserve the case received via EPP. -TG- This needs to be specified perhaps for contact fields for example. As it, reads now you register ExAmPlE.com but you cannot return, example.com. Least that is how I read it. The domain object in the RDAP response MUST contain entities with the following roles. Exactly one entity per role MUST be present in the response. -TG-Most gTLDs support more roles. Is there no support or does the policy ends this support for more roles? -RDAP does not support a country code for a contact, rather RDAP requires a full country name. -TG- This, is a mapping nightmare, not everyone supports the official mapping, not sure how much work this is and will vary from Registrar to Registrar. If the queried domain name is allocated, the following applies: If allocated variant domain names exist for the queried domain name, or if the domain name is an allocated variant domain name, the domain object in the RDAP response MUST contain a variants member [RFC7483]. -TG- We do not store this, and it seems to contradict the following in the profile :"The purpose of this profile is to specify the RDAP requirements that are in line with the current Whois service requirements." Best regards, Theo On 24-9-2016 20:10, Dennis Chang wrote: Hi Theo, This is the first item on the agenda for the IRT meeting on Tuesday. Please keep the questions coming. If you could provide specifics on “irregularities within RDAP” and “clarification on a few issues” in advance, that will help us to prepare better for our team discussion. Thanks Dennis Chang From: theo geurts <gtheo@xs4all.nl><mailto:gtheo@xs4all.nl> Date: Thursday, September 22, 2016 at 1:16 AM To: "Anderson, Marc" <mcanderson@verisign.com><mailto:mcanderson@verisign.com>, Dennis Chang <dennis.chang@icann.org><mailto:dennis.chang@icann.org>, "gnso-impl-thickwhois-rt@icann.org"<mailto:gnso-impl-thickwhois-rt@icann.org> <gnso-impl-thickwhois-rt@icann.org><mailto:gnso-impl-thickwhois-rt@icann.org> Subject: Re: [Gnso-impl-thickwhois-rt] Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration Dennis, This looks like the path forward, and I am supportive of the proposed path forward as a Registrar. Perhaps I am jumping the gun here, but how would this dialogue with the community take place? Furthermore, how do we address irregularities within RDAP? Or get clarification on a few issues that I assume have not been discussed yet? Thanks, Theo On 21-9-2016 19:58, Anderson, Marc wrote: Dennis, Thank you for the excellent explanation and details. On behalf of Verisign and as a member of the RySG I would like to express my support for the revised CL&D policy and the path forward you have laid out. Thank you, Marc Anderson From: gnso-impl-thickwhois-rt-bounces@icann.org<mailto:gnso-impl-thickwhois-rt-bounces@icann.org> [mailto:gnso-impl-thickwhois-rt-bounces@icann.org] On Behalf Of Dennis Chang Sent: Wednesday, September 21, 2016 1:42 PM To: gnso-impl-thickwhois-rt@icann.org<mailto:gnso-impl-thickwhois-rt@icann.org> Subject: [Gnso-impl-thickwhois-rt] Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration Dear IRT members, As you know, on 7 February 2014, the ICANN Board adopted GNSO consensus policy recommendations regarding the provision of “Thick” Whois by all gTLD registries. In consultation with the consensus policy Implementation Review Team (IRT), the implementation team identified two expected outcomes in the policy development process (PDP) recommendations: * The consistent labeling and display of WHOIS output for all gTLDs * The transition from Thin to Thick WHOIS for .COM, .NET and .JOBS The first outcome was published as a consensus policy, the Registry Registration Data Directory Services Consistent Labeling and Display Policy[icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources...> (CL&D Policy), on 26 July 2016. In August 2016, the Registry Stakeholder Group (RySG) submitted a Request for Reconsideration[icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources...> (RfR) regarding the CL&D Policy. The RfR objects to the inclusion of RDAP as part of the Consensus Policy as RDAP was not contemplated or referenced in the policy recommendations. To resolve this matter, ICANN proposes the following path forward for the IRT: 1. ICANN to issue a revised CL&D Policy to all registry operators, removing provision 12. For your reference, provision 12 states: “The implementation of an RDAP service in accordance with the "RDAP Operational Profile for gTLD Registries and Registrars[icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_rdap-2Dgt...>" is required for all gTLD registries in order to achieve consistent labeling and display.” Additionally, I have attached the proposed revised CL&D Policy. 2. Issue a revised notification to registry operators regarding implementation of the CL&D Policy, clearly indicating what has changed in the revised CL&D Policy. 3. Set the revised CL&D Policy effective date to allow for full 6-month implementation from the date of the revised notice. 4. Update the published CL&D Policy on the ICANN website, noting a change has been made. Note: The revised CL&D Policy would not be subject to another Public Comment process. 5. Rescind the notification sent to registrars to implement RDAP. ICANN intends to issue notices for registries and registrars to implement RDAP after further dialogue with the community. Please let us know if you have comments or concerns by responding to this list. Unless we hear otherwise, we intend to move forward with the plan outlined above on 4 October 2016. — Kind Regards, Dennis S. Chang GDD Services & Engagement Program Director +1 213 293 7889 Skype: dennisSchang www.icann.org[icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.icann.org&d=DQMDaQ&c...> "One World, One Internet" _______________________________________________ Gnso-impl-thickwhois-rt mailing list Gnso-impl-thickwhois-rt@icann.org<mailto:Gnso-impl-thickwhois-rt@icann.org> https://mm.icann.org/mailman/listinfo/gnso-impl-thickwhois-rt[mm.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Dimpl-2Dthickwhois-2Drt&d=DQMDaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=dqLP1wJqBvDSYLKrSEaAkCi_Kv0Mk5D_d32n29DHCN8&m=pkBrE3ogDYFgpWAATzOOdmRD93_Pz1PCrWtnSZN7Lg4&s=4kbspuXnx6QwVFowMkdtINMgbQE8VDBSKEyWHfD8wDo&e=>
Hi Francisco, Thanks for the clarifications, very helpful. Regarding this transition, I was not aware this was pending community discussion, My guess outside of the ICANN bubble very few are aware. It is now clear to me that the two should coexist. But the RAA 2013 is less clear when it comes to this subject (the reason I brought this up). Registration Data Directory Services. U/ntil ICANN requires a different protocol, Registrar will operate a WHOIS service available via port 43 in accordance with RFC 3912, and a web-based Directory Service providing free public query-based access to at least the elements set forth in Section 3.3.1.1 through 3.3.1.8 of the Registrar Accreditation Agreement in the format set forth in Section 1.4 of this Specification. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registrar will implement such alternative specification as soon as reasonably practicable./ Now we can have several interpretations on how we could read this, but one of the interpretations could be, implement RDAP and your requirement for the port 43 service is no longer required, as it is replaced by RDAP. In short, the RAA 2013 does not specify what to do. The email that was sent out a few weeks ago about RDAP did not specify what to do, besides implementing it. As such you might have Registrars come up with their own interpretation. But perhaps I am the only one who sees an issue here. Talk to you folks on the call in a few. Theo On 27-9-2016 02:33, Francisco Arias wrote:
[Apologies for not replying inline, the new version of Outlook won’t let me.]
The date for shutting down Whois port 43 has not been discussed or defined with the community. Therefore, stating 1 February 2017 we would be in the transition period where both WHOIS and RDAP would coexist.
The requirement for having a valid DNSSEC chain of trust is not coming from the RDAP RFCs; this is a requirement from the gTLD RDAP profile that was discussed and agreed with the community.
The requirement to preserve case is a “SHOULD” not a “MUST”, hence following your example, the contracted party would be free to return “example.com”.
The gTLD RDAP profile requires registrant, technical and administrative, and optionally allows for a billing contact. The gTLD profile addresses how to support more roles (e.g., contacts), for example, see section 1.3.6 of the profile.
Regarding variants, section 1.5.17 of the profile addresses this: /In the case of Registrars, the variants member MUST reflect the latest known set of variant domain names and relation types./
Regards,
--
Francisco
On 9/26/16, 5:05 AM, "gnso-impl-thickwhois-rt-bounces@icann.org <mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of theo geurts" <gnso-impl-thickwhois-rt-bounces@icann.org <mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of gtheo@xs4all.nl <mailto:gtheo@xs4all.nl>> wrote:
Thanks Dennis,
First of all, if we look what has been published is that RDAP should be implemented Feb 1, 2017 (draft 1 April). What I am missing, is a transition period. If everyone implements it, and shuts down the WHOIS servers we have a problem.
The resource records related to the RDAP service MUST be signed with DNSSEC, and the DNSSEC chain of trust from the root trust anchor to the name of the RDAP server MUST be valid at all times. -Looks sensible, but I cannot find this in the RFC's mentioned, is the above language a result of this?
In the case (i.e. uppercase and lowercase) of the data returned in RDAP responses SHOULD preserve the case received via EPP. -TG- This needs to be specified perhaps for contact fields for example. As it, reads now you register ExAmPlE.com but you cannot return, example.com. Least that is how I read it.
The domain object in the RDAP response MUST contain entities with the following roles. Exactly one entity per role MUST be present in the response. -TG-Most gTLDs support more roles. Is there no support or does the policy ends this support for more roles?
-RDAP does not support a country code for a contact, rather RDAP requires a full country name. -TG- This, is a mapping nightmare, not everyone supports the official mapping, not sure how much work this is and will vary from Registrar to Registrar.
If the queried domain name is allocated, the following applies: If allocated variant domain names exist for the queried domain name, or if the domain name is an allocated variant domain name, the domain object in the RDAP response MUST contain a variants member [RFC7483]. -TG- We do not store this, and it seems to contradict the following in the profile :"The purpose of this profile is to specify the RDAP requirements that are in line with the current Whois service requirements."
Best regards,
Theo
On 24-9-2016 20:10, Dennis Chang wrote:
Hi Theo,
This is the first item on the agenda for the IRT meeting on Tuesday.
Please keep the questions coming.
If you could provide specifics on “irregularities within RDAP” and “clarification on a few issues” in advance, that will help us to prepare better for our team discussion.
Thanks
Dennis Chang
*From: *theo geurts <gtheo@xs4all.nl> <mailto:gtheo@xs4all.nl> *Date: *Thursday, September 22, 2016 at 1:16 AM *To: *"Anderson, Marc" <mcanderson@verisign.com> <mailto:mcanderson@verisign.com>, Dennis Chang <dennis.chang@icann.org> <mailto:dennis.chang@icann.org>, "gnso-impl-thickwhois-rt@icann.org" <mailto:gnso-impl-thickwhois-rt@icann.org> <gnso-impl-thickwhois-rt@icann.org> <mailto:gnso-impl-thickwhois-rt@icann.org> *Subject: *Re: [Gnso-impl-thickwhois-rt] Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration
Dennis,
This looks like the path forward, and I am supportive of the proposed path forward as a Registrar.
Perhaps I am jumping the gun here, but how would this dialogue with the community take place? Furthermore, how do we address irregularities within RDAP? Or get clarification on a few issues that I assume have not been discussed yet?
Thanks,
Theo
On 21-9-2016 19:58, Anderson, Marc wrote:
Dennis,
Thank you for the excellent explanation and details. On behalf of Verisign and as a member of the RySG I would like to express my support for the revised CL&D policy and the path forward you have laid out.
Thank you,
Marc Anderson
*From:*gnso-impl-thickwhois-rt-bounces@icann.org <mailto:gnso-impl-thickwhois-rt-bounces@icann.org> [mailto:gnso-impl-thickwhois-rt-bounces@icann.org] *On Behalf Of *Dennis Chang *Sent:* Wednesday, September 21, 2016 1:42 PM *To:* gnso-impl-thickwhois-rt@icann.org <mailto:gnso-impl-thickwhois-rt@icann.org> *Subject:* [Gnso-impl-thickwhois-rt] Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration
Dear IRT members,
As you know, on 7 February 2014, the ICANN Board adopted GNSO consensus policy recommendations regarding the provision of “Thick” Whois by all gTLD registries.
In consultation with the consensus policy Implementation Review Team (IRT), the implementation team identified two expected outcomes in the policy development process (PDP) recommendations:
* The consistent labeling and display of WHOIS output for all gTLDs * The transition from Thin to Thick WHOIS for .COM, .NET and .JOBS
The first outcome was published as a consensus policy, the Registry Registration Data Directory Services Consistent Labeling and Display Policy[icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources...> (CL&D Policy), on 26 July 2016.
In August 2016, the Registry Stakeholder Group (RySG) submitted a Request for Reconsideration[icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources...> (RfR) regarding the CL&D Policy. The RfR objects to the inclusion of RDAP as part of the Consensus Policy as RDAP was not contemplated or referenced in the policy recommendations.
To resolve this matter, ICANN proposes the following path forward for the IRT:
1. ICANN to issue a revised CL&D Policy to all registry operators, removing provision 12. For your reference, provision 12 states: “The implementation of an RDAP service in accordance with the "RDAP Operational Profile for gTLD Registries and Registrars[icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_rdap-2Dgt...>" is required for all gTLD registries in order to achieve consistent labeling and display.” Additionally, I have attached the proposed revised CL&D Policy.
2. Issue a revised notification to registry operators regarding implementation of the CL&D Policy, clearly indicating what has changed in the revised CL&D Policy.
3. Set the revised CL&D Policy effective date to allow for full 6-month implementation from the date of the revised notice.
4. Update the published CL&D Policy on the ICANN website, noting a change has been made. Note: The revised CL&D Policy would _not_ be subject to another Public Comment process.
5. Rescind the notification sent to registrars to implement RDAP.
ICANN intends to issue notices for registries and registrars to implement RDAP after further dialogue with the community.
Please let us know if you have comments or concerns by responding to this list. Unless we hear otherwise, we intend to move forward with the plan outlined above on 4 October 2016.
—
Kind Regards,
Dennis S. Chang
GDD Services & Engagement Program Director
+1 213 293 7889
Skype: dennisSchang
www.icann.org[icann.org] <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.icann.org&d=DQMDaQ&c...> "One World, One Internet"
_______________________________________________
Gnso-impl-thickwhois-rt mailing list
Gnso-impl-thickwhois-rt@icann.org <mailto:Gnso-impl-thickwhois-rt@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-impl-thickwhois-rt[mm.icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...>
Hi Francisco, it is not as easy as you make it:
The date for shutting down Whois port 43 has not been discussed or defined with the community. Therefore, stating 1 February 2017 we would be in the transition period where both WHOIS and RDAP would coexist.
There does not have to be a date for registrars that have submitted all data to the newly thick registry. According to section 3.3.1 of the 2013 RAA, the registrar can switch off its whois servers the second the registry becomes thick for the data relating to the domains registered through him. There is no "transition time" after the upload has completed and the registry has begun outputting whois for these domains on their end. So you will see a period where some registrars are still outputting their whois themselves while others will have already switched it off: 3.3.1 At its expense, Registrar shall provide an interactive web page and, *with respect to any **gTLD**operating a "thin" registry*, a port 43 Whois service (each accessible via both IPv4 and IPv6) providing free public query-based access to up-to-date (i.e., updated at least daily) *data**concerning all active Registered Names sponsored by Registrar in any **gTLD*.
The requirement for having a valid DNSSEC chain of trust is not coming from the RDAP RFCs; this is a requirement from the gTLD RDAP profile that was discussed and agreed with the community.
Was it now? Can you provide the exact reference to this agreement? I am not aware of this having passed the GNSO Council.
Regarding variants, section 1.5.17 of the profile addresses this: /In the case of Registrars, the variants member MUST reflect the latest known set of variant domain names and relation types./
/What profile are you referring to here? The profile described in the RAA has no section 1.5.17. Best, Volker /
Regards,
--
Francisco
On 9/26/16, 5:05 AM, "gnso-impl-thickwhois-rt-bounces@icann.org <mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of theo geurts" <gnso-impl-thickwhois-rt-bounces@icann.org <mailto:gnso-impl-thickwhois-rt-bounces@icann.org> on behalf of gtheo@xs4all.nl <mailto:gtheo@xs4all.nl>> wrote:
Thanks Dennis,
First of all, if we look what has been published is that RDAP should be implemented Feb 1, 2017 (draft 1 April). What I am missing, is a transition period. If everyone implements it, and shuts down the WHOIS servers we have a problem.
The resource records related to the RDAP service MUST be signed with DNSSEC, and the DNSSEC chain of trust from the root trust anchor to the name of the RDAP server MUST be valid at all times. -Looks sensible, but I cannot find this in the RFC's mentioned, is the above language a result of this?
In the case (i.e. uppercase and lowercase) of the data returned in RDAP responses SHOULD preserve the case received via EPP. -TG- This needs to be specified perhaps for contact fields for example. As it, reads now you register ExAmPlE.com but you cannot return, example.com. Least that is how I read it.
The domain object in the RDAP response MUST contain entities with the following roles. Exactly one entity per role MUST be present in the response. -TG-Most gTLDs support more roles. Is there no support or does the policy ends this support for more roles?
-RDAP does not support a country code for a contact, rather RDAP requires a full country name. -TG- This, is a mapping nightmare, not everyone supports the official mapping, not sure how much work this is and will vary from Registrar to Registrar.
If the queried domain name is allocated, the following applies: If allocated variant domain names exist for the queried domain name, or if the domain name is an allocated variant domain name, the domain object in the RDAP response MUST contain a variants member [RFC7483]. -TG- We do not store this, and it seems to contradict the following in the profile :"The purpose of this profile is to specify the RDAP requirements that are in line with the current Whois service requirements."
Best regards,
Theo
On 24-9-2016 20:10, Dennis Chang wrote:
Hi Theo,
This is the first item on the agenda for the IRT meeting on Tuesday.
Please keep the questions coming.
If you could provide specifics on “irregularities within RDAP” and “clarification on a few issues” in advance, that will help us to prepare better for our team discussion.
Thanks
Dennis Chang
*From: *theo geurts <gtheo@xs4all.nl> <mailto:gtheo@xs4all.nl> *Date: *Thursday, September 22, 2016 at 1:16 AM *To: *"Anderson, Marc" <mcanderson@verisign.com> <mailto:mcanderson@verisign.com>, Dennis Chang <dennis.chang@icann.org> <mailto:dennis.chang@icann.org>, "gnso-impl-thickwhois-rt@icann.org" <mailto:gnso-impl-thickwhois-rt@icann.org> <gnso-impl-thickwhois-rt@icann.org> <mailto:gnso-impl-thickwhois-rt@icann.org> *Subject: *Re: [Gnso-impl-thickwhois-rt] Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration
Dennis,
This looks like the path forward, and I am supportive of the proposed path forward as a Registrar.
Perhaps I am jumping the gun here, but how would this dialogue with the community take place? Furthermore, how do we address irregularities within RDAP? Or get clarification on a few issues that I assume have not been discussed yet?
Thanks,
Theo
On 21-9-2016 19:58, Anderson, Marc wrote:
Dennis,
Thank you for the excellent explanation and details. On behalf of Verisign and as a member of the RySG I would like to express my support for the revised CL&D policy and the path forward you have laid out.
Thank you,
Marc Anderson
*From:*gnso-impl-thickwhois-rt-bounces@icann.org <mailto:gnso-impl-thickwhois-rt-bounces@icann.org> [mailto:gnso-impl-thickwhois-rt-bounces@icann.org] *On Behalf Of *Dennis Chang *Sent:* Wednesday, September 21, 2016 1:42 PM *To:* gnso-impl-thickwhois-rt@icann.org <mailto:gnso-impl-thickwhois-rt@icann.org> *Subject:* [Gnso-impl-thickwhois-rt] Proposed Path Forward | Thick Whois CL&D Policy, RDAP and RySG Request for Reconsideration
Dear IRT members,
As you know, on 7 February 2014, the ICANN Board adopted GNSO consensus policy recommendations regarding the provision of “Thick” Whois by all gTLD registries.
In consultation with the consensus policy Implementation Review Team (IRT), the implementation team identified two expected outcomes in the policy development process (PDP) recommendations:
* The consistent labeling and display of WHOIS output for all gTLDs * The transition from Thin to Thick WHOIS for .COM, .NET and .JOBS
The first outcome was published as a consensus policy, the Registry Registration Data Directory Services Consistent Labeling and Display Policy[icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources...> (CL&D Policy), on 26 July 2016.
In August 2016, the Registry Stakeholder Group (RySG) submitted a Request for Reconsideration[icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources...> (RfR) regarding the CL&D Policy. The RfR objects to the inclusion of RDAP as part of the Consensus Policy as RDAP was not contemplated or referenced in the policy recommendations.
To resolve this matter, ICANN proposes the following path forward for the IRT:
1. ICANN to issue a revised CL&D Policy to all registry operators, removing provision 12. For your reference, provision 12 states: “The implementation of an RDAP service in accordance with the "RDAP Operational Profile for gTLD Registries and Registrars[icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_rdap-2Dgt...>" is required for all gTLD registries in order to achieve consistent labeling and display.” Additionally, I have attached the proposed revised CL&D Policy.
2. Issue a revised notification to registry operators regarding implementation of the CL&D Policy, clearly indicating what has changed in the revised CL&D Policy.
3. Set the revised CL&D Policy effective date to allow for full 6-month implementation from the date of the revised notice.
4. Update the published CL&D Policy on the ICANN website, noting a change has been made. Note: The revised CL&D Policy would _not_ be subject to another Public Comment process.
5. Rescind the notification sent to registrars to implement RDAP.
ICANN intends to issue notices for registries and registrars to implement RDAP after further dialogue with the community.
Please let us know if you have comments or concerns by responding to this list. Unless we hear otherwise, we intend to move forward with the plan outlined above on 4 October 2016.
—
Kind Regards,
Dennis S. Chang
GDD Services & Engagement Program Director
+1 213 293 7889
Skype: dennisSchang
www.icann.org[icann.org] <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.icann.org&d=DQMDaQ&c...> "One World, One Internet"
_______________________________________________
Gnso-impl-thickwhois-rt mailing list
Gnso-impl-thickwhois-rt@icann.org <mailto:Gnso-impl-thickwhois-rt@icann.org>
https://mm.icann.org/mailman/listinfo/gnso-impl-thickwhois-rt[mm.icann.org] <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...>
_______________________________________________ Gnso-impl-thickwhois-rt mailing list Gnso-impl-thickwhois-rt@icann.org https://mm.icann.org/mailman/listinfo/gnso-impl-thickwhois-rt
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
participants (5)
-
Anderson, Marc -
Dennis Chang -
Francisco Arias -
theo geurts -
Volker Greimann