The Verisign Engineering team that is responsible for implementing RDAP in our production environment has reviewed the draft operational profile. Their comments are included below. Scott ---------- Verisign has read the proposed RDAP Profile and we have comments on the following sections. In addition to the commentary on the items addressed in the profile, we wish to express our hope that the profile will be expanded to address authentication and authorization. Merely replacing existing port43 WHOIS with JSON-formatted data misses an opportunity to improve upon deficiencies in WHOIS. Respectfully, Verisign Follow-up to publication of ICANN's RDAP profile: 1.3.2: "The RDAP service MUST be provided only over HTTPS. The TLS certificate used for the RDAP service must be issued by a Certificate Authority (CA) trusted by major browsers and mobile OS such as the ones listed in the Mozilla Included CA Certificate List (https://wiki.mozilla.org/CA:IncludedCAs). The CA, the certificate and its usage MUST follow the CAB Forum Baseline Requirements (https://cabforum.org/baseline-requirements-documents). The RDAP service MUST use the best practices for secure use of TLS as described in RFC7525 or its successors." Comment: The above seem to be guidelines missing specifics. Is the certificate used by the RDAP service domain-validated or organization-validated? What ciphers should be supported? 1.3.4/1.3: "RDAP extensions, if used, MUST be registered in the IANA's RDAP Extensions registry (https://www.iana.org/assignments/rdap-extensions/rdap-extensions.xhtml), as defined in RFC7480. Deployment of RDAP extensions in gTLD Registries operated under agreement with ICANN, are subject to approval by ICANN via the RSEP process." Comment: The above is contrary to the implication from Sec 2.1 of RFC 7483 that "Clients of these JSON responses SHOULD ignore unrecognized JSON members in responses" - this definitely indicates that unregistered or new RDAP extensions may be used without being formally registered as an RDAP extension. We believe it appropriate to change the "MUST" in this section to "SHOULD". One benefit of defining the RDAP protocol is extensibility, and this profile shouldn't be unnecessarily restrictive. 1.4.3: "The case (i.e. uppercase and lowercase) of the data returned in RDAP responses MUST be preserved." Comment: It is unclear where the original input of the data returned in RDAP response was derived from - are we referring to the EPP data sent by registrars during registration or is the reference specifically for the capitalization mode used in the RDAP request. Why is this a requirement? 1.4.12: "RDAP responses MUST contain the last update date and time of the database used to generate the RDAP responses (RDAP database in this document) when an RFC defining this capability has been published. The RDAP database MUST include the registration data in the SRS database. The RDAP database must be updated within the allowed Service Level Requirement (SLR) (e.g. RDDS update time, ≤ 60 minutes). In a case where the contracted party is querying its SRS database directly, and therefore, using real-time data, this date and time will show the timestamp of the response to the query." Comment: We suggest that this be specified with a new field such as "icann_db_timestamp" encoded in the top-level object instead of defining a new event. 1.5.2: "The top-level domain object in the RDAP response MUST contain the U-label format of the domain in the unicodeName member [RFC7483], only if the domain name is an IDN." Comment: For an IDN domain name, specifying 2 different encodings in the same response seems redundant and leads to wasted bandwidth. Why is the a-label not sufficient? 1.5.8: "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, each of them with a handle" Comment: This seems to suggest that a prerequisite for implementing RDAP is that the top-level domain (TLD) contain "thick" registry data. That would seem to preclude the deployment of .COM and .NET RDAP services till the registries are fully converted into "thick" registries. 1.5.14: "The domain object in the RDAP response MUST contain the following events:...An event with the expiration date of the Registrar, when a RFC defining this capability has been published" Comment: Is this meant to apply to registries? Domains at the registry typically auto-renew so they usually do not expire. If it does not apply to registries, this requirement should be moved to Section 3. If it does apply, this implies that a change in the EPP specification is required before the registry can derive this information for the domain. 1.5.17: "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]. The variants relation member MUST contain valid variant relation types as defined in the IANA's RDAP JSON Values registry. If the queried domain name is an allocated variant name, the original name MUST be included in the variants member." Comment: The first sentence of this item is unclear. Is the intent that a queried (and allocated) domain having possible variants provide *allocated* variants in the reply? Is the intent that queried names that are variants of an allocated domains produce a domain response with the allocated name as the domain object? The expected behavior should be clarified through examples. 1.5.18: "A domain name RDAP response MUST contain a remarks member with a title "EPP Status Codes", a description containing the string "For more information on domain status codes, please visit https://icann.org/epp" and a links member with the https://icann.org/epp URL." Comment: Should the status definitions be defined on a top-level object instead of using a "remarks" member? This could be handled much like the suggestion for 1.4.12, with an "icann_" prefix. 1.5.19: "The domain object in the RDAP response MUST contain a secureDNS member [RFC7483] including at least a delegationSigned element. Other elements (e.g. dsData, maxSigLife) of the secureDNS member MUST be included, if the domain name is signed and the elements are known by the server." Comment: The above is ambiguous - what exactly is meant by "known to the server"? This phrasing should be changed to "stored by the registry or registrar". 2.1: "Registries offering searchable Whois service (e.g., per exhibit A of their RA) MUST support RDAP search requests for domains and entities. Entities MUST be searchable by name search pattern as defined in RFC7482 section 3.2.3 in order to allow for searches by contact name or address. Boolean search capabilities (AND, OR) MUST be supported, when a RFC defining this capability has been published." Comment: We believe the purpose of this profile is to define expected behaviors of a complaint RDAP implementation for registries and registrars. It should not mandate compliance with some future, yet-to-be defined RFC and, therefore, the reference to boolean search should be removed. 2.3: "If a Registry supports multiple host objects with the same name, the Registry MUST support the capability to respond with a set of host objects in response to a name server lookup, when an RFC defining this capability has been published." Comment: As with 2.1, the purpose of the profile is to define expectations of conforming registries and registrars, not mandate compliance with undefined requirements. 2.4: "The RDAP domain lookup response MUST contain a links object as defined in RFC7483 section 4.2. The links object MUST contain the elements rel:related and href pointing to the Registrar's RDAP URL of the queried domain object." This requirement is unclear. A domain lookup response will contain a domain object, potentially having links to other objects, including a link back to the domain object itself. The "rel" element is optional in the RFC for good reason; if it's to be required, then the value should be either "self" or "related" depending on whether the link is back to the queried domain object, or to a related object. Regardless, the mandate for such an element is unnecessary and therefore questionable. 2.9.1: "Entity RDAP queries (registrar queries): The returned RDAP response MUST be an entity with registrar role, with a handle (IANA Registrar ID) and valid elements fn, adr, tel, email. Registrar object lookup using an entity search on the fn element MUST be supported." The above implies that Entities are only registrars which conflicts with the RFC definition of Entities as Contacts AND Registrars. It is also not stated that a Registry may only provide information on Registrars that are contracted to resell domains of a specific TLD - this list is not necessarily exhaustive or representative of a list of all registrars - that information is stored with ICANN and IANA.