Draft Updated WHOIS Clarification Advisory v.20141209
Hello colleagues, Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-201 4-09-12-en). This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list. A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org. Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call. It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA. Regards, Gustavo ICANN
Dear Gustavo, In an example (a query for a domain name without name servers) you state two possible outputs. It strikes me as odd, that a non-delegated domain name gives the result signedDelegation for DNSSEC. There is no delegation, least a signed one. True? Regards, Marc Groeneweg From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Gustavo Lozano Sent: woensdag 10 december 2014 1:41 To: gtld-tech@icann.org Cc: Fabien Betremieux Subject: [gtld-tech] Draft Updated WHOIS Clarification Advisory v.20141209 * PGP - S/MIME Signed by an unverified key: 10-12-2014 at 1:41:09 Hello colleagues, Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014...). This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list. A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org<mailto:fabien.betremieux@icann.org>. Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call. It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA. Regards, Gustavo ICANN * Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>> * Issuer: DigiCert Inc - Unverified
Gustavo, Fabien, thanks for the update, and for addressing some of the issues that we discussed. I have reviewed the current draft version, and my feedback is as follows: - MINOR: I.1 could still be improved regarding the seperation between registries and registrars. Since the Section title says that the clarification applies to both registries and registrars, and the clarification mentions both Agreements, this could be misinterpreted as that both parties have to show all fields from both agreements - which is not intended, as i understood. Adding something like "section 1.4.2 of the RDDS spec of the 2013 RAA (applicable to Registrars only) .." would make it clear with minimal text impact. - MINOR: Furthermore, I.1 just mentions section 1.5 of the Registry Agreement (which contains the domain object example), but does not mention 1.6 and 1.7 of the Agreement (which contains examples of the registrar and nameserver objecT). Is that intentional? Clarification I.13 for example mentions all three sections... - MAJOR: I.27 "Domain Name registrations MUST have one and only one administrative contact" is either badly written, or goes beyond the ICANN-defined purpose of the document, because "Domain Name Registrations" in my opinion would also concern the input side (EPP), so that would be beyond scope of the WHOIS clarifications. I don't see that requirement in the Registry agreement, and also EPP allows several "admin-c" contact - furthermore, as discussed in Honolulu, several Registry operator do allow more than one admin-c. Therefore, my assumption is that this should read either: o "_WHOIS output of_ Domain Name Registrations MUST have one and only one administrative contact" (in case it was really intended to limit the admin-c output to one instance, as discussed in HNL), or o "Domain Name registrations MUST have one and only one _registrant_ contact" (which would be in-line with the EPP input side, but seems like a redundant requirement then) - MEDIUM: I.28/I.30/I.32 - i'm confused by the reference to I.28, because there doesn't seem to be much of a choice in whether or not to implement I.28 ("MUST NOT")? So, given that there is no choice in I.28, that means that any registry has to implement I.30 (and no registry can implement I.32). That means that I.30 seems to be a new requirement? Given that Gustavo and Francisco said that there is no intention to add new requirements via the clarifications, this should probably be changed/clarified. - MEDIUM: I.34 seems to be a new requirement as well. I do understand, however, that since this is just a SHOULD, registries can elect to not support that new type of query? Particularly, since (as described below), the authoritative source for any information about an IANA-registered registrar should be IANA / ICANN itself, rather than the individual registries... - More on a general note, i'm confused why registries are required to supply such rich information for Registrars (including several contacts). Essentially, information in the registry WHOIS could be reduced to displaying the IANA ID (and maybe the name, WHOIS server and registrar URL for convenience), because the set of registrars in all registries is defined to be a subset of the IANA registrar registry anyways, and hence authoritative data can be fetched from the Registrar's own WHOIS, or even IANA and/or ICANN itself.. tia, Alex Von: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] Im Auftrag von Gustavo Lozano Gesendet: Mittwoch, 10. Dezember 2014 01:41 An: gtld-tech@icann.org Cc: Fabien Betremieux Betreff: [gtld-tech] Draft Updated WHOIS Clarification Advisory v.20141209 Hello colleagues, Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014...). This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list. A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org<mailto:fabien.betremieux@icann.org>. Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call. It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA. Regards, Gustavo ICANN
Alex Registrant contact and administrative contact have different meanings and powers under the ICANN policies, so I'm not sure which one it should be, but it cannot be changed arbitrarily Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://www.blacknight.press - get our latest news & media coverage http://www.technology.ie Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Social: http://mneylon.social ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Alexander Mayrhofer Sent: 11 December 2014 12:54 To: Gustavo Lozano; gtld-tech@icann.org Cc: Fabien Betremieux Subject: Re: [gtld-tech] Draft Updated WHOIS Clarification Advisory v.20141209 Gustavo, Fabien, thanks for the update, and for addressing some of the issues that we discussed. I have reviewed the current draft version, and my feedback is as follows: - MINOR: I.1 could still be improved regarding the seperation between registries and registrars. Since the Section title says that the clarification applies to both registries and registrars, and the clarification mentions both Agreements, this could be misinterpreted as that both parties have to show all fields from both agreements - which is not intended, as i understood. Adding something like "section 1.4.2 of the RDDS spec of the 2013 RAA (applicable to Registrars only) .." would make it clear with minimal text impact. - MINOR: Furthermore, I.1 just mentions section 1.5 of the Registry Agreement (which contains the domain object example), but does not mention 1.6 and 1.7 of the Agreement (which contains examples of the registrar and nameserver objecT). Is that intentional? Clarification I.13 for example mentions all three sections... - MAJOR: I.27 "Domain Name registrations MUST have one and only one administrative contact" is either badly written, or goes beyond the ICANN-defined purpose of the document, because "Domain Name Registrations" in my opinion would also concern the input side (EPP), so that would be beyond scope of the WHOIS clarifications. I don't see that requirement in the Registry agreement, and also EPP allows several "admin-c" contact - furthermore, as discussed in Honolulu, several Registry operator do allow more than one admin-c. Therefore, my assumption is that this should read either: o "_WHOIS output of_ Domain Name Registrations MUST have one and only one administrative contact" (in case it was really intended to limit the admin-c output to one instance, as discussed in HNL), or o "Domain Name registrations MUST have one and only one _registrant_ contact" (which would be in-line with the EPP input side, but seems like a redundant requirement then) - MEDIUM: I.28/I.30/I.32 - i'm confused by the reference to I.28, because there doesn't seem to be much of a choice in whether or not to implement I.28 ("MUST NOT")? So, given that there is no choice in I.28, that means that any registry has to implement I.30 (and no registry can implement I.32). That means that I.30 seems to be a new requirement? Given that Gustavo and Francisco said that there is no intention to add new requirements via the clarifications, this should probably be changed/clarified. - MEDIUM: I.34 seems to be a new requirement as well. I do understand, however, that since this is just a SHOULD, registries can elect to not support that new type of query? Particularly, since (as described below), the authoritative source for any information about an IANA-registered registrar should be IANA / ICANN itself, rather than the individual registries... - More on a general note, i'm confused why registries are required to supply such rich information for Registrars (including several contacts). Essentially, information in the registry WHOIS could be reduced to displaying the IANA ID (and maybe the name, WHOIS server and registrar URL for convenience), because the set of registrars in all registries is defined to be a subset of the IANA registrar registry anyways, and hence authoritative data can be fetched from the Registrar's own WHOIS, or even IANA and/or ICANN itself.. tia, Alex Von: gtld-tech-bounces@icann.org<mailto:gtld-tech-bounces@icann.org> [mailto:gtld-tech-bounces@icann.org] Im Auftrag von Gustavo Lozano Gesendet: Mittwoch, 10. Dezember 2014 01:41 An: gtld-tech@icann.org<mailto:gtld-tech@icann.org> Cc: Fabien Betremieux Betreff: [gtld-tech] Draft Updated WHOIS Clarification Advisory v.20141209 Hello colleagues, Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014...). This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list. A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org<mailto:fabien.betremieux@icann.org>. Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call. It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA. Regards, Gustavo ICANN
Well, If that is true, then we have a terminology problem, and the document should define what entity or data portion is referred to for each of the contact types... Alex Von: Michele Neylon - Blacknight [mailto:michele@blacknight.com] Gesendet: Donnerstag, 11. Dezember 2014 14:04 An: Alexander Mayrhofer; Gustavo Lozano; gtld-tech@icann.org Cc: Fabien Betremieux Betreff: RE: [gtld-tech] Draft Updated WHOIS Clarification Advisory v.20141209 Alex Registrant contact and administrative contact have different meanings and powers under the ICANN policies, so I'm not sure which one it should be, but it cannot be changed arbitrarily Regards Michele -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains http://www.blacknight.host/ http://blog.blacknight.com/ http://www.blacknight.press - get our latest news & media coverage http://www.technology.ie Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Social: http://mneylon.social ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845 From: gtld-tech-bounces@icann.org<mailto:gtld-tech-bounces@icann.org> [mailto:gtld-tech-bounces@icann.org] On Behalf Of Alexander Mayrhofer Sent: 11 December 2014 12:54 To: Gustavo Lozano; gtld-tech@icann.org<mailto:gtld-tech@icann.org> Cc: Fabien Betremieux Subject: Re: [gtld-tech] Draft Updated WHOIS Clarification Advisory v.20141209 Gustavo, Fabien, thanks for the update, and for addressing some of the issues that we discussed. I have reviewed the current draft version, and my feedback is as follows: - MINOR: I.1 could still be improved regarding the seperation between registries and registrars. Since the Section title says that the clarification applies to both registries and registrars, and the clarification mentions both Agreements, this could be misinterpreted as that both parties have to show all fields from both agreements - which is not intended, as i understood. Adding something like "section 1.4.2 of the RDDS spec of the 2013 RAA (applicable to Registrars only) .." would make it clear with minimal text impact. - MINOR: Furthermore, I.1 just mentions section 1.5 of the Registry Agreement (which contains the domain object example), but does not mention 1.6 and 1.7 of the Agreement (which contains examples of the registrar and nameserver objecT). Is that intentional? Clarification I.13 for example mentions all three sections... - MAJOR: I.27 "Domain Name registrations MUST have one and only one administrative contact" is either badly written, or goes beyond the ICANN-defined purpose of the document, because "Domain Name Registrations" in my opinion would also concern the input side (EPP), so that would be beyond scope of the WHOIS clarifications. I don't see that requirement in the Registry agreement, and also EPP allows several "admin-c" contact - furthermore, as discussed in Honolulu, several Registry operator do allow more than one admin-c. Therefore, my assumption is that this should read either: o "_WHOIS output of_ Domain Name Registrations MUST have one and only one administrative contact" (in case it was really intended to limit the admin-c output to one instance, as discussed in HNL), or o "Domain Name registrations MUST have one and only one _registrant_ contact" (which would be in-line with the EPP input side, but seems like a redundant requirement then) - MEDIUM: I.28/I.30/I.32 - i'm confused by the reference to I.28, because there doesn't seem to be much of a choice in whether or not to implement I.28 ("MUST NOT")? So, given that there is no choice in I.28, that means that any registry has to implement I.30 (and no registry can implement I.32). That means that I.30 seems to be a new requirement? Given that Gustavo and Francisco said that there is no intention to add new requirements via the clarifications, this should probably be changed/clarified. - MEDIUM: I.34 seems to be a new requirement as well. I do understand, however, that since this is just a SHOULD, registries can elect to not support that new type of query? Particularly, since (as described below), the authoritative source for any information about an IANA-registered registrar should be IANA / ICANN itself, rather than the individual registries... - More on a general note, i'm confused why registries are required to supply such rich information for Registrars (including several contacts). Essentially, information in the registry WHOIS could be reduced to displaying the IANA ID (and maybe the name, WHOIS server and registrar URL for convenience), because the set of registrars in all registries is defined to be a subset of the IANA registrar registry anyways, and hence authoritative data can be fetched from the Registrar's own WHOIS, or even IANA and/or ICANN itself.. tia, Alex Von: gtld-tech-bounces@icann.org<mailto:gtld-tech-bounces@icann.org> [mailto:gtld-tech-bounces@icann.org] Im Auftrag von Gustavo Lozano Gesendet: Mittwoch, 10. Dezember 2014 01:41 An: gtld-tech@icann.org<mailto:gtld-tech@icann.org> Cc: Fabien Betremieux Betreff: [gtld-tech] Draft Updated WHOIS Clarification Advisory v.20141209 Hello colleagues, Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014...). This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list. A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org<mailto:fabien.betremieux@icann.org>. Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call. It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA. Regards, Gustavo ICANN
Hi Gustavo, I do have some comments on the document. Paragraph 7. Why the requirement for the URL description of the EPP status? It looks ugly, and is redundant if the requirement of paragraph 23 is included. Paragraph 11: Please tell me if I'm misunderstanding this. Why the requirement that additional fields proceed all the text specified in the RA? I would expect additional information related to the domain to go with the domain, and additional fields related to the registrant go with the rest of the registrant info for example. For a human this would make more sense and be more readable, and for machine parsing the order should make no difference anyway as long as the fields don't use any of the names in the RA/RAA. Finally let me add my voice to those who have said that this advisory DOES add new requirements, and if the extremely detailed definitions of the text layout are really required then this is effectively a new protocol. I would much rather ICANN move towards the RDAP protocol than attempt to stretch port 80 RDDS in directions it was never intended to go. Thanks. Ed.
Gustavo, In reviewing the updated document, I have the following feedback. Overall, the clarification document attempts to define ICANN’s desired Whois Server behavior. It is clearly defining new requirements and not providing clarifications to existing ones. The Thick Whois work may define a completely new set of requirements that may collide with these ever growing set of requirements, and still without any formal specification. Is there anyway to combine these Whois efforts that considers the existing Whois Server behavior, the desired behavior, and with the goal to define a unified Whois specification that the community can collaborate on and implement to? Providing clarifications to clarifications based on an incomplete set of requirements in the registry and registrar agreements to eventually form the desired end state for Whois is highly disruptive, highly inefficient, and expensive. Please take a step back with all of this and come up with a path forward that helps attain the goal of a consistent Whois interface with minimal cost and complexity. The upcoming RDAP should also be considered with this effort. Thank you for adding the “2) no field MUST be shown” option for non-existent fields in clarification 1. Clarification 11 still makes the order of keys significant. The 2013 RAA and the Registry Agreement do not explicitly state that the order of keys is significant. The clarification document is defining brand new requirements for ordered display of keys that breaks existing convention. For example, why put the billing contact information separate from the rest of the contact information? Why put the Internationalized Domain Name field far away from the Domain Name field? Why put the Phone Ext and Fax Ext fields of the Registrar contacts far away from the Phone and Fax fields? As noted previously, the most important item for parsers is for the keys to be the same, where the order is not significant. My recommendation is to specify just the set of keys and define the format of the values. The revised text “(ie. no partial match or other search ability capabilities, only exact match lookup).” in clarification 18 and the new clarification 23 “WHOIS (port-43) queries for name server object MUST NOT offer partial match or other searchable capabilities.” went in the opposite direction to the feedback provided at IETF-91 and on the gtld-tech list. Prohibiting existing Whois Server functionality across multiple registries is a new requirement that has not been discussed, has not been justified, and is beyond the scope of a clarifications document. The partial match functionality has existed for a long time and is a useful feature for clients. What is the basis for ignoring the feedback and attempting to remove this useful feature in a clarifications document? As requested previously, please remove clarification 18 and now the new clarification 28. New clarification 26 is new behavior. We currently return ‘No match for “<QUERY>”.’ for non-existent entities. What do other Whois servers return? Can we have a discussion around what is the appropriate behavior for queries of non-existent entities prior to adding a new requirement? New item 27 “Domain Name registration MUST have one and only one administration contact” seems to go beyond what is displayed in Whois. Can you clarify the clarification and also clarify why administration contacts are handled differently from tech and billing contacts? I believe that clarification 30 should reference clarification 29 instead of 28. For the new clarification 31, why is partial matching for Registrar data allowed but prohibited for domain and name servers? Partial match for domain and name servers is existing behavior and more useful. I believe that clarification 32 should reference clarification 29 instead of 28. New clarification 38 ‘When receiving unqualified query (i.e., a query string that does not include the “nameserver” or “registrar” parameters) that matches a domain name and a name server object, the registry MUST return the information about the domain name object.’ is a new requirement. Existing Whois implementations return all domain, nameserver, and registrar matches on an unqualified query. This again is more than a simple clarification, but a fundamental change in Whois Server behavior. Clarification 40 “Responses to registrar object queries MUST show at least one admin contact and one technical contact” is another new requirement. At a minimum this should be set as SHOULD instead of MUST. Thanks, — JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Dec 9, 2014, at 7:41 PM, Gustavo Lozano <gustavo.lozano@icann.org> wrote:
Hello colleagues,
Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014...).
This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list.
A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org.
Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call.
It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA.
Regards, Gustavo ICANN <Registry and Registrar RDDS Advisory - 1.0 vs 20141209[1][1].docx><Registry and Registrar RDDS Advisory - 20141209[3].docx>
Hi, One quick comment: One of the objectives of these clarifications is to retain the ability to easily parse the output. Interested users are encouraged to consider the clarifications below when developing parsers for RDDS output. The above objective doesn't seem much different from RDAP's one. I'm afraid the clarified WHOIS specification might reduce motivation to support RDAP. I'm curious about how we would migrate between WHOIS and RDAP in future. Regards, Naoki Kambe
Dear Gustavo, I still have some questions after the last WHOIS clarification draft. 1. Q2 states ' In responses to domain name object queries: 1) to registries, and 2) to registrars for names in “thick” registries, the following fields are considered optional and should be treated as described in clarification 1’. That means that those fields are optional for all type of registries, ‘thick’ and ‘thin’? 2. Q21: what is meant by a fully qualified domain name? Is this with or without the dot at the end? I’m asking because the rfc’s usually refer to a fully qualified domain name when there should be a dot at the end. But in the examples in the WHOIS clarifications document are all without a dot behind the tld. 3. Q27 is quite confusing. I hope we are still talking about the output of a WHOIS domain name query and not overruling the rfc's? Assuming that this is just about the output, I find this clarification not necessary because it can be derived from other clarifications. Q24 says that fields cannot appear multiple times, unless the fields mentioned in Q25. Together with Q1, this makes that admin and tech contacts can only to appear once in the output. 4. About Q37, we will not have admin and tech contacts for registrars in our registry system, only for domain names. Did I miss a requirement somewhere that says we should? If there is no such requirement, what should we display in the output of a registrar WHOIS query? Can we treat them as optional fields? 5. My forth question is also valid for Q40. 6. Q42 says that the ‘WHOIS server’ field is considered optional in case the registrar doesn’t offer a WHOIS on port 43. Why is the ‘Referral URL’ not mention in this clarification? Are registrars obligated to offer a web-based WHOIS service and not to offer a WHOIS service on port 43? I would also need some clarifications in case the registry uses host attributes instead of host objects. At the moment these are missing. The questions we already have about this: 1. Section 1.7 of Specification 4 of the registry agreement defines the fields we will have to show in the output of a WHOIS nameserver query. Amongst those fields there are also registrar specific fields as ‘Registrar’, ‘WHOIS server’ and ‘Referral URL’. Since we will be using host attributes instead of host objects, we will not have this data available. Can we handle these fields as optional fields? 2. Section 1.7.1 of Specification 4 of the registry agreement defines the WHOIS queries that should be supported for nameservers. For the first query format there is an example nameserver ’NS1.EXAMPLE.TLD' used but for the second and third query format there is no example but a description '(nameserver name)’. This is confusing because it makes me wonder what the difference between 'NS1.EXAMPLE.TLD’ and '(nameserver name)’ is, besides de brackets of course. Kind regards, Loesje Hermans Functional Analyst +32 16 29 89 23 DNS Belgium vzw/asbl Ubicenter - Philipssite 5, bus 13 - 3001 Leuven www.dnsbelgium.be<http://www.dnsbelgium.be/> [cid:09ee086c0b7e41ef0f09e359060c1a61f817d422@zimbra] On 10 Dec 2014, at 01:41, Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>> wrote: Hello colleagues, Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014...). This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list. A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org<mailto:fabien.betremieux@icann.org>. Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call. It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA. Regards, Gustavo ICANN <Registry and Registrar RDDS Advisory - 1.0 vs 20141209[1][1].docx><Registry and Registrar RDDS Advisory - 20141209[3].docx>
Besides some specific comments below, the general comment I want to make is that these changes serves no real purpose for the community. They try to define an strict output format that is not required either by any reasonably-implemented parsing interface nor by any reasonable human being. Any undergraduate student can use YACC/Bison to write a parser that could easily grasp for all the possibilities the original agreement, even without clarifications, could generate. BTW, I guess one actual implementation out there (https://gwhois.org/ <https://gwhois.org/>) used a much simpler architecture to adequately respond to different registry implementations. That said, some specific comments: - Clarification numbers don't match between the two documents, and sometimes inside the documents the wrong clarification is mentioned. The documents need some revising. - Host attributes registries were clearly forgotten in the design. There are no ROID's for name servers in host attributes registries, and if IP addresses are removed from domain queries, they won't appear in any query. - It also assumes registrars have admin/techcontacts. There was no such requirement in the agreements. - It tries to change a tradition of referral-URL to point to web-whois instead; it's possibly better to keep it the way it's currently used, and instead display port-43 registrar WHOIS server (if available) in port-43 registry WHOIS, but display WEB-WHOIS registrar WHOIS server in registry WEB-WHOIS. - There are lots of new query types and behaviors; all of them constitute new requirements. They both generate a significant one-time developing workload and also generate compliance risks for registries that don't whether to follow the original agreement or a misplaced clarifications documents that has no basis on the agreement. My suggestions to improve this process: - Do not try to establish any type of parameter response order other than being intelligible by a reasonable human being. RDAP is the proper response for syntactically constructed queries and responses. - Do not force any parameter that is optional to have a blank response. This only makes the WHOIS output less under stable by human beings, which will continue to be the main customers of this information. - Do not try to force data models that weren't there at the first place, like registrar contacts - Do not prevent IP addresses from being shown in in-bailwick name servers, although making such behavior optional for host-objects registries - Do not put any of this in a document called "clarifications". Make them part of the ongoing agreement negotiation between registries and ICANN for the registries part and evoke RAA negotiation for the registrars part, or make all of it part of a consensus policy so all contracted parties act on it simultaneously. Trying to bypass process does not look good here. Rubens
Em 09/12/2014, à(s) 22:41:000, Gustavo Lozano <gustavo.lozano@icann.org> escreveu:
Hello colleagues,
Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014...).
This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list.
A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org.
Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call.
It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA.
Regards, Gustavo ICANN <Registry and Registrar RDDS Advisory - 1.0 vs 20141209[1][1].docx><Registry and Registrar RDDS Advisory - 20141209[3].docx>
@All, Here follows an structured response to all of the December 12 proposed WHOIS clarifications. I divided them in four categories: - Actual clarifications, marked in green. - Optional enhancements (format changes that are optional in nature so they don't require effort from registries that do not want to make them, but allowing the ones who do to implement such improvements). Also marked in green. - WHOIS format changes: changes to either output, format or semantics. These are changes that I think as permissible under the agreement, but not if ICANN call them clarifications; they should be called format changes in order to account for their real impact and provide ample time for registries to implement. It also should be noted that since they are not consensus policies, these changes might also be regulated by RRAs between registries and registrars, so beyond some reasonable time to implement (135 days is possible a starting point since it's the number for RDAP), it might also require to fit into the schedule of allowed changes to registry systems. 180 days is a condition that is usual in RRAs, so registries with such limitations should be able to get longer exemptions from ICANN. Marked in yellow. - Registry change: changes that imply registry system data model or behaviour changes. Marked in red. For those changes there are no other venues than consensus policies and RA amendments, they simply do not fit in anything allowed by specification 4, and are likely to be quashed in the agreement and bylaws defined ways. Some recommendations have more than one part so a few of them are marked in more than one column. The registrar-only recommendations are listed in the workbook but not currently commented, but my guess is they will have a similar distribution of clarifications, simple changes and changes requiring a complete revamp of the system. Rubens NIC.br <http://nic.br/>
On Dec 9, 2014, at 10:41 PM, Gustavo Lozano <gustavo.lozano@icann.org> wrote:
Hello colleagues,
Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014...).
This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list.
A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org.
Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call.
It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA.
Regards, Gustavo ICANN <Registry and Registrar RDDS Advisory - 1.0 vs 20141209[1][1].docx><Registry and Registrar RDDS Advisory - 20141209[3].docx>
Rubens, Thanks for putting together the spreadsheet. I reviewed the spreadsheet and added my comments prefixed with “JG - “ in the attachment. — JG [cid:c613066d-3cfe-4126-836c-ed76ee960a9a@verisign.com] James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://VerisignInc.com> On Dec 17, 2014, at 9:41 PM, Rubens Kuhl <rubensk@nic.br<mailto:rubensk@nic.br>> wrote: @All, Here follows an structured response to all of the December 12 proposed WHOIS clarifications. I divided them in four categories: - Actual clarifications, marked in green. - Optional enhancements (format changes that are optional in nature so they don't require effort from registries that do not want to make them, but allowing the ones who do to implement such improvements). Also marked in green. - WHOIS format changes: changes to either output, format or semantics. These are changes that I think as permissible under the agreement, but not if ICANN call them clarifications; they should be called format changes in order to account for their real impact and provide ample time for registries to implement. It also should be noted that since they are not consensus policies, these changes might also be regulated by RRAs between registries and registrars, so beyond some reasonable time to implement (135 days is possible a starting point since it's the number for RDAP), it might also require to fit into the schedule of allowed changes to registry systems. 180 days is a condition that is usual in RRAs, so registries with such limitations should be able to get longer exemptions from ICANN. Marked in yellow. - Registry change: changes that imply registry system data model or behaviour changes. Marked in red. For those changes there are no other venues than consensus policies and RA amendments, they simply do not fit in anything allowed by specification 4, and are likely to be quashed in the agreement and bylaws defined ways. Some recommendations have more than one part so a few of them are marked in more than one column. The registrar-only recommendations are listed in the workbook but not currently commented, but my guess is they will have a similar distribution of clarifications, simple changes and changes requiring a complete revamp of the system. Rubens NIC.br<http://nic.br/> On Dec 9, 2014, at 10:41 PM, Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>> wrote: Hello colleagues, Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014...). This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list. A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org<mailto:fabien.betremieux@icann.org>. Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call. It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA. Regards, Gustavo ICANN <Registry and Registrar RDDS Advisory - 1.0 vs 20141209[1][1].docx><Registry and Registrar RDDS Advisory - 20141209[3].docx> <ResponseToWHOISClarifications.xlsx>
James, I've incorporated most of your comments in this new document; I renamed it to "Contracted Parties Response" in the hope that we get feedback from other registries and from registrars. I'll comment on a minor architecture detail in another message in order not to lose focus on the main issues. Rubens
On Dec 19, 2014, at 8:43 PM, Gould, James <JGould@verisign.com> wrote:
Rubens,
Thanks for putting together the spreadsheet. I reviewed the spreadsheet and added my comments prefixed with “JG - “ in the attachment.
—
JG
<BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>
James Gould Distinguished Engineer jgould@Verisign.com <x-msg://80/jgould@Verisign.com>
703-948-3271 12061 Bluemont Way Reston, VA 20190
VerisignInc.com <http://verisigninc.com/> On Dec 17, 2014, at 9:41 PM, Rubens Kuhl <rubensk@nic.br <mailto:rubensk@nic.br>> wrote:
@All,
Here follows an structured response to all of the December 12 proposed WHOIS clarifications. I divided them in four categories: - Actual clarifications, marked in green. - Optional enhancements (format changes that are optional in nature so they don't require effort from registries that do not want to make them, but allowing the ones who do to implement such improvements). Also marked in green. - WHOIS format changes: changes to either output, format or semantics. These are changes that I think as permissible under the agreement, but not if ICANN call them clarifications; they should be called format changes in order to account for their real impact and provide ample time for registries to implement. It also should be noted that since they are not consensus policies, these changes might also be regulated by RRAs between registries and registrars, so beyond some reasonable time to implement (135 days is possible a starting point since it's the number for RDAP), it might also require to fit into the schedule of allowed changes to registry systems. 180 days is a condition that is usual in RRAs, so registries with such limitations should be able to get longer exemptions from ICANN. Marked in yellow. - Registry change: changes that imply registry system data model or behaviour changes. Marked in red. For those changes there are no other venues than consensus policies and RA amendments, they simply do not fit in anything allowed by specification 4, and are likely to be quashed in the agreement and bylaws defined ways.
Some recommendations have more than one part so a few of them are marked in more than one column.
The registrar-only recommendations are listed in the workbook but not currently commented, but my guess is they will have a similar distribution of clarifications, simple changes and changes requiring a complete revamp of the system.
Rubens NIC.br <http://nic.br/>
On Dec 9, 2014, at 10:41 PM, Gustavo Lozano <gustavo.lozano@icann.org <mailto:gustavo.lozano@icann.org>> wrote:
Hello colleagues,
Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014... <https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014...>).
This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list.
A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org <mailto:fabien.betremieux@icann.org>.
Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call.
It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA.
Regards, Gustavo ICANN <Registry and Registrar RDDS Advisory - 1.0 vs 20141209[1][1].docx><Registry and Registrar RDDS Advisory - 20141209[3].docx>
<ResponseToWHOISClarifications.xlsx>
<ResponseToWHOISClarifications - JG.xlsx>
James, My point on WHOIS database is the possibility of an on-demand cache-driven database. Let's the WHOIS server is the front-end for a cache database that queries the SRS only for objects that are older than x minutes; in this way, the WHOIS database is made of specific entries like "example.TLD - datetime of cached query - query result", where result can be both the information or the non-existence of the domain. This database doesn't have or need transactional capabilities and can be either NoSQL or in-memory depending on registry profile. Such an architecture has no concept of a global last updated timestamp, because it's built record by record based on query pattern. Rubens
On Dec 19, 2014, at 8:43 PM, Gould, James <JGould@verisign.com> wrote:
Rubens,
Thanks for putting together the spreadsheet. I reviewed the spreadsheet and added my comments prefixed with “JG - “ in the attachment.
—
JG
<BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>
James Gould Distinguished Engineer jgould@Verisign.com <x-msg://83/jgould@Verisign.com>
703-948-3271 12061 Bluemont Way Reston, VA 20190
VerisignInc.com <http://verisigninc.com/> On Dec 17, 2014, at 9:41 PM, Rubens Kuhl <rubensk@nic.br <mailto:rubensk@nic.br>> wrote:
@All,
Here follows an structured response to all of the December 12 proposed WHOIS clarifications. I divided them in four categories: - Actual clarifications, marked in green. - Optional enhancements (format changes that are optional in nature so they don't require effort from registries that do not want to make them, but allowing the ones who do to implement such improvements). Also marked in green. - WHOIS format changes: changes to either output, format or semantics. These are changes that I think as permissible under the agreement, but not if ICANN call them clarifications; they should be called format changes in order to account for their real impact and provide ample time for registries to implement. It also should be noted that since they are not consensus policies, these changes might also be regulated by RRAs between registries and registrars, so beyond some reasonable time to implement (135 days is possible a starting point since it's the number for RDAP), it might also require to fit into the schedule of allowed changes to registry systems. 180 days is a condition that is usual in RRAs, so registries with such limitations should be able to get longer exemptions from ICANN. Marked in yellow. - Registry change: changes that imply registry system data model or behaviour changes. Marked in red. For those changes there are no other venues than consensus policies and RA amendments, they simply do not fit in anything allowed by specification 4, and are likely to be quashed in the agreement and bylaws defined ways.
Some recommendations have more than one part so a few of them are marked in more than one column.
The registrar-only recommendations are listed in the workbook but not currently commented, but my guess is they will have a similar distribution of clarifications, simple changes and changes requiring a complete revamp of the system.
Rubens NIC.br <http://nic.br/>
On Dec 9, 2014, at 10:41 PM, Gustavo Lozano <gustavo.lozano@icann.org <mailto:gustavo.lozano@icann.org>> wrote:
Hello colleagues,
Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014... <https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014...>).
This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list.
A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org <mailto:fabien.betremieux@icann.org>.
Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call.
It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA.
Regards, Gustavo ICANN <Registry and Registrar RDDS Advisory - 1.0 vs 20141209[1][1].docx><Registry and Registrar RDDS Advisory - 20141209[3].docx>
<ResponseToWHOISClarifications.xlsx>
<ResponseToWHOISClarifications - JG.xlsx>
Let me say it is even more complicated as it will be attribute by attribute as what attributes can be displayed have to do with various legislative rules, for example inability to show certain attributes if the registrant is a natural person (as compared with an organisation), who requests the data etc. Patrik
On 20 dec 2014, at 02:32, Rubens Kuhl <rubensk@nic.br> wrote:
James,
My point on WHOIS database is the possibility of an on-demand cache-driven database. Let's the WHOIS server is the front-end for a cache database that queries the SRS only for objects that are older than x minutes; in this way, the WHOIS database is made of specific entries like "example.TLD - datetime of cached query - query result", where result can be both the information or the non-existence of the domain. This database doesn't have or need transactional capabilities and can be either NoSQL or in-memory depending on registry profile.
Such an architecture has no concept of a global last updated timestamp, because it's built record by record based on query pattern.
Rubens
On Dec 19, 2014, at 8:43 PM, Gould, James <JGould@verisign.com <mailto:JGould@verisign.com>> wrote:
Rubens,
Thanks for putting together the spreadsheet. I reviewed the spreadsheet and added my comments prefixed with “JG - “ in the attachment.
—
JG
<BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png>
James Gould Distinguished Engineer jgould@Verisign.com <x-msg://83/jgould@Verisign.com>
703-948-3271 12061 Bluemont Way Reston, VA 20190
VerisignInc.com <http://verisigninc.com/> On Dec 17, 2014, at 9:41 PM, Rubens Kuhl <rubensk@nic.br <mailto:rubensk@nic.br>> wrote:
@All,
Here follows an structured response to all of the December 12 proposed WHOIS clarifications. I divided them in four categories: - Actual clarifications, marked in green. - Optional enhancements (format changes that are optional in nature so they don't require effort from registries that do not want to make them, but allowing the ones who do to implement such improvements). Also marked in green. - WHOIS format changes: changes to either output, format or semantics. These are changes that I think as permissible under the agreement, but not if ICANN call them clarifications; they should be called format changes in order to account for their real impact and provide ample time for registries to implement. It also should be noted that since they are not consensus policies, these changes might also be regulated by RRAs between registries and registrars, so beyond some reasonable time to implement (135 days is possible a starting point since it's the number for RDAP), it might also require to fit into the schedule of allowed changes to registry systems. 180 days is a condition that is usual in RRAs, so registries with such limitations should be able to get longer exemptions from ICANN. Marked in yellow. - Registry change: changes that imply registry system data model or behaviour changes. Marked in red. For those changes there are no other venues than consensus policies and RA amendments, they simply do not fit in anything allowed by specification 4, and are likely to be quashed in the agreement and bylaws defined ways.
Some recommendations have more than one part so a few of them are marked in more than one column.
The registrar-only recommendations are listed in the workbook but not currently commented, but my guess is they will have a similar distribution of clarifications, simple changes and changes requiring a complete revamp of the system.
Rubens NIC.br <http://nic.br/>
On Dec 9, 2014, at 10:41 PM, Gustavo Lozano <gustavo.lozano@icann.org <mailto:gustavo.lozano@icann.org>> wrote:
Hello colleagues,
Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014... <https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014...>).
This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list.
A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org <mailto:fabien.betremieux@icann.org>.
Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call.
It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA.
Regards, Gustavo ICANN <Registry and Registrar RDDS Advisory - 1.0 vs 20141209[1][1].docx><Registry and Registrar RDDS Advisory - 20141209[3].docx>
<ResponseToWHOISClarifications.xlsx>
<ResponseToWHOISClarifications - JG.xlsx>
I think that we should focus here on the narrower set of issues that we have been addressing. There are no differences in the gTLD contract with respect to the nature of the registrant, and I don’t believe that the two successful RSEPs that have granted exemptions to Whois requirements involved that kind of question. Whether there should be differences is another matter. Don From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Patrik Fältström Sent: Saturday, December 20, 2014 3:06 AM To: Rubens Kuhl Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] Draft Updated WHOIS Clarification Advisory v.20141209 Let me say it is even more complicated as it will be attribute by attribute as what attributes can be displayed have to do with various legislative rules, for example inability to show certain attributes if the registrant is a natural person (as compared with an organisation), who requests the data etc. Patrik On 20 dec 2014, at 02:32, Rubens Kuhl <rubensk@nic.br<mailto:rubensk@nic.br>> wrote: James, My point on WHOIS database is the possibility of an on-demand cache-driven database. Let's the WHOIS server is the front-end for a cache database that queries the SRS only for objects that are older than x minutes; in this way, the WHOIS database is made of specific entries like "example.TLD - datetime of cached query - query result", where result can be both the information or the non-existence of the domain. This database doesn't have or need transactional capabilities and can be either NoSQL or in-memory depending on registry profile. Such an architecture has no concept of a global last updated timestamp, because it's built record by record based on query pattern. Rubens On Dec 19, 2014, at 8:43 PM, Gould, James <JGould@verisign.com<mailto:JGould@verisign.com>> wrote: Rubens, Thanks for putting together the spreadsheet. I reviewed the spreadsheet and added my comments prefixed with “JG - “ in the attachment. — JG <BF09FAA4-32D8-46E0-BED0-CD72F43BD6E0[81].png> James Gould Distinguished Engineer jgould@Verisign.com<x-msg://83/jgould@Verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com<http://verisigninc.com/> On Dec 17, 2014, at 9:41 PM, Rubens Kuhl <rubensk@nic.br<mailto:rubensk@nic.br>> wrote: @All, Here follows an structured response to all of the December 12 proposed WHOIS clarifications. I divided them in four categories: - Actual clarifications, marked in green. - Optional enhancements (format changes that are optional in nature so they don't require effort from registries that do not want to make them, but allowing the ones who do to implement such improvements). Also marked in green. - WHOIS format changes: changes to either output, format or semantics. These are changes that I think as permissible under the agreement, but not if ICANN call them clarifications; they should be called format changes in order to account for their real impact and provide ample time for registries to implement. It also should be noted that since they are not consensus policies, these changes might also be regulated by RRAs between registries and registrars, so beyond some reasonable time to implement (135 days is possible a starting point since it's the number for RDAP), it might also require to fit into the schedule of allowed changes to registry systems. 180 days is a condition that is usual in RRAs, so registries with such limitations should be able to get longer exemptions from ICANN. Marked in yellow. - Registry change: changes that imply registry system data model or behaviour changes. Marked in red. For those changes there are no other venues than consensus policies and RA amendments, they simply do not fit in anything allowed by specification 4, and are likely to be quashed in the agreement and bylaws defined ways. Some recommendations have more than one part so a few of them are marked in more than one column. The registrar-only recommendations are listed in the workbook but not currently commented, but my guess is they will have a similar distribution of clarifications, simple changes and changes requiring a complete revamp of the system. Rubens NIC.br<http://nic.br/> On Dec 9, 2014, at 10:41 PM, Gustavo Lozano <gustavo.lozano@icann.org<mailto:gustavo.lozano@icann.org>> wrote: Hello colleagues, Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014...). This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list. A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org<mailto:fabien.betremieux@icann.org>. Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call. It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA. Regards, Gustavo ICANN <Registry and Registrar RDDS Advisory - 1.0 vs 20141209[1][1].docx><Registry and Registrar RDDS Advisory - 20141209[3].docx> <ResponseToWHOISClarifications.xlsx> <ResponseToWHOISClarifications - JG.xlsx>
Gustavo, Thank you for setting up the call to discuss this. One of the items discussed on the call was support for partial matches. We previously requested for item 18 “WHOIS queries for domain name MUST return only one record per query” to be removed. This was further discussed at IETF-91. On the call there was confusion on whether other registries supported the partial match feature. Please note per the meeting minutes ( http://mm.icann.org/pipermail/gtld-tech/2014-November/000363.html ) that I posted to the gtld-tech list, that states "Multiple registries support wildcard queries in WHOIS, where if more than one object (domain or host) matches the query name ( with or without TLD ), a list of matching names is returned instead of a single record.” I confirmed this by connecting to a sample of the old and new gTLD WHOIS servers, that showed that at least three other registries support partial match. Not only was the feedback disregarded, but the language was tightened in clarification 18 and a new clarification 28 was added that further prohibited the feature. The reason stated on the call to forbid this feature was that it wasn’t explicitly defined in Specification 4 of the Registry Agreement. This feature exists solely for the benefit of the end user and should not be disallowed in a clarifications document with no real compelling reason. Following the discussion on the partial match we discussed clarification 30, which defines support for querying name servers by roid. In clarification 30, ICANN defines a new feature that is also not explicitly allowed in Specification 4 of the Registry Agreement. The reason stated on the call for adding this feature in the clarifications document was that ICANN felt it provided value to the end user. In the clarifications document ICANN is taking an inconsistent approach to their interpretation of Specification 4. Please stop using a clarifications document to disallow features you don’t like and add features you want. Thanks, — JG James Gould Distinguished Engineer jgould@Verisign.com 703-948-3271 12061 Bluemont Way Reston, VA 20190 VerisignInc.com On Dec 9, 2014, at 7:41 PM, Gustavo Lozano <gustavo.lozano@icann.org> wrote:
Hello colleagues,
Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014...).
This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list.
A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org.
Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call.
It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA.
Regards, Gustavo ICANN <Registry and Registrar RDDS Advisory - 1.0 vs 20141209[1][1].docx><Registry and Registrar RDDS Advisory - 20141209[3].docx>
Gustavo, others, I am very concerned over the discussion and the way feedback is taken care of. SSAC did already in SAC-055 say no constructive movement forward will be achieved unless certain base agreements have been achieved. Specifically SSAC say:
The SSAC believes that there is a critical need for a policy defining the purpose of collecting and maintaining registration data. This policy should address the operational concerns of the parties who collect, maintain or use this data as it relates to ICANN’s remit. The policy should address at least the following questions:
• Why are data collected?
• What purpose will the data serve?
• Who collects the data?
• Where is the data stored and how long is it stored?
• Where is the data escrowed and how long is it escrowed?
• Who needs the data and why?
• Who needs access to logs of access to the data and why?
Until there is agreement on these questions (and possibly more), I do not see there be any possibility to any of the issues ICANN just continue and continue to propose solutions to. For example, even if I personally have been working with whois protocol and issues since 1993 or so, I find it being very hard to engage in the discussion as the questions above being adressed, in a global context with global legislative issues related to data protection taken into account. Patrik Fältström SSAC Chair
On 10 dec 2014, at 01:41, Gustavo Lozano <gustavo.lozano@icann.org> wrote:
Hello colleagues,
Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014...).
This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list.
A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org.
Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call.
It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA.
Regards, Gustavo ICANN <Registry and Registrar RDDS Advisory - 1.0 vs 20141209[1][1].docx><Registry and Registrar RDDS Advisory - 20141209[3].docx>
Patrik That would all be within the remit of policy creation not clarification Regards Michele Mr Michele Neylon Blacknight Hosting & Domains http://www.blacknight.host/ http://www.mneylon.social Sent from mobile so typos and brevity are normal
On 20 Dec 2014, at 09:23, Patrik Fältström <paf@frobbit.se> wrote:
Gustavo, others,
I am very concerned over the discussion and the way feedback is taken care of.
SSAC did already in SAC-055 say no constructive movement forward will be achieved unless certain base agreements have been achieved. Specifically SSAC say:
The SSAC believes that there is a critical need for a policy defining the purpose of collecting and maintaining registration data. This policy should address the operational concerns of the parties who collect, maintain or use this data as it relates to ICANN’s remit. The policy should address at least the following questions:
• Why are data collected?
• What purpose will the data serve?
• Who collects the data?
• Where is the data stored and how long is it stored?
• Where is the data escrowed and how long is it escrowed?
• Who needs the data and why?
• Who needs access to logs of access to the data and why?
Until there is agreement on these questions (and possibly more), I do not see there be any possibility to any of the issues ICANN just continue and continue to propose solutions to.
For example, even if I personally have been working with whois protocol and issues since 1993 or so, I find it being very hard to engage in the discussion as the questions above being adressed, in a global context with global legislative issues related to data protection taken into account.
Patrik Fältström SSAC Chair
On 10 dec 2014, at 01:41, Gustavo Lozano <gustavo.lozano@icann.org> wrote:
Hello colleagues,
Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014...).
This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list.
A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org.
Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call.
It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA.
Regards, Gustavo ICANN <Registry and Registrar RDDS Advisory - 1.0 vs 20141209[1][1].docx><Registry and Registrar RDDS Advisory - 20141209[3].docx>
Michele, Absolutely, I agree, but I just wanted to explain why it is hard to find agreed to good language for clarifications to a policy people disagree with, and do not understand, or have different interpretations of. Patrik
On 20 dec 2014, at 19:16, Michele Neylon - Blacknight <michele@blacknight.com> wrote:
Patrik That would all be within the remit of policy creation not clarification Regards Michele
Mr Michele Neylon Blacknight Hosting & Domains http://www.blacknight.host/ http://www.mneylon.social Sent from mobile so typos and brevity are normal
On 20 Dec 2014, at 09:23, Patrik Fältström <paf@frobbit.se> wrote:
Gustavo, others,
I am very concerned over the discussion and the way feedback is taken care of.
SSAC did already in SAC-055 say no constructive movement forward will be achieved unless certain base agreements have been achieved. Specifically SSAC say:
The SSAC believes that there is a critical need for a policy defining the purpose of collecting and maintaining registration data. This policy should address the operational concerns of the parties who collect, maintain or use this data as it relates to ICANN’s remit. The policy should address at least the following questions:
• Why are data collected?
• What purpose will the data serve?
• Who collects the data?
• Where is the data stored and how long is it stored?
• Where is the data escrowed and how long is it escrowed?
• Who needs the data and why?
• Who needs access to logs of access to the data and why?
Until there is agreement on these questions (and possibly more), I do not see there be any possibility to any of the issues ICANN just continue and continue to propose solutions to.
For example, even if I personally have been working with whois protocol and issues since 1993 or so, I find it being very hard to engage in the discussion as the questions above being adressed, in a global context with global legislative issues related to data protection taken into account.
Patrik Fältström SSAC Chair
On 10 dec 2014, at 01:41, Gustavo Lozano <gustavo.lozano@icann.org> wrote:
Hello colleagues,
Attached you will find the Draft Updated WHOIS Clarification Advisory. Two versions are provided for your reference: clean version and redline against the original advisory (v 1.0) as published on 12 September 2014 (https://www.icann.org/resources/pages/registry-agreement-spec4-raa-rdds-2014...).
This draft version incorporates feedback gathered from various contracted parties, cases/emails sent to ICANN, the WHOIS Clarification Advisory meeting held at IETF 91 in November, and feedback sent to the gtld-tech mailing list.
A conference call, with the objective of gathering feedback on this draft version, will take place on Tuesday 16 December 2014. If you want to participate in the conference call, please send me an email to fabien.betremieux@icann.org.
Please send any feedback or questions you have on this version of the advisory to the mailing list as soon as possible, in order for ICANN Staff to discuss internally and provide an answer during the conference call.
It's important to remember: * This advisory is not meant to create new requirements for contracted parties. * This advisory is not meant to redefine the WHOIS protocol. * This advisory resulted from questions sent by contracted and third parties seeking clarification on the Whois (RDDS) requirements in the New gTLD base RA and 2013 RAA.
Regards, Gustavo ICANN <Registry and Registrar RDDS Advisory - 1.0 vs 20141209[1][1].docx><Registry and Registrar RDDS Advisory - 20141209[3].docx>
participants (11)
-
Alexander Mayrhofer -
Don Blumenthal -
Ed Pascoe -
Gould, James -
Gustavo Lozano -
Loesje Hermans -
Marc Groeneweg -
Michele Neylon - Blacknight -
Naoki Kambe -
Patrik Fältström -
Rubens Kuhl