- gtld-tech - lists.icann.org

RDAP Port 43 Value
by Brian Mountford Nov. 3, 2015

Nov. 3, 2015

RFC 7483, section 4.7 talks about the port43 member, which is supposed to name the WHOIS server where the object can be found. As a registry, are we supposed to set this value to our WHOIS server, or to the registrar's? The WHOIS protocol has a similar field, which is supposed to be the registrar's server. But that takes the form of a URL, whereas RDAP port43 is explicitly not a URL. So I'm not sure what we are to put in the field, and I couldn't find any directives in the profile document. Thanks. Brian

1 0

Re: [gtld-tech] [weirds] gTLD RDAP profile meeting during IETF94
by Francisco Arias Nov. 3, 2015

Nov. 3, 2015

Dear colleagues, We have room 419 in the IETF venue from 9:00 - 12:00 on Wednesday, 4-Nov (local time). Anyone interested in discussing the draft gTLD RDAP profile is welcome. Feel free to circulate this. Regards, -- Francisco. On 10/14/15, 5:18 PM, "weirds on behalf of Gustavo Lozano" <weirds-bounces(a)ietf.org<mailto:weirds-bounces@ietf.org> on behalf of gustavo.lozano(a)icann.org<mailto:gustavo.lozano@icann.org>> wrote: Hello, [Apologies if you receive multiple copies of this email] Are you interested in meeting during IETF94 in order to discuss the gTLD RDAP profile (see http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html)? If there is enough interest, I could request a room. Remote participation would be provided if there is interest. Regards, Gustavo

1 1

Re: [gtld-tech] gtld-tech Digest, Vol 30, Issue 23
by Brian Mountford Oct. 30, 2015

Oct. 30, 2015

And is weirds(a)ietf.org a list I would need to join somehow, akin to this list? Or do I just send a message? On Fri, Oct 30, 2015 at 8:00 AM, <gtld-tech-request(a)icann.org> wrote: > Send gtld-tech mailing list submissions to > gtld-tech(a)icann.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mm.icann.org/mailman/listinfo/gtld-tech > or, via email, send a message with subject or body 'help' to > gtld-tech-request(a)icann.org > > You can reach the person managing the list at > gtld-tech-owner(a)icann.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of gtld-tech digest..." > > > Today's Topics: > > 1. RDAP Questions (Brian Mountford) > 2. Re: RDAP Questions (Andrew Sullivan) > 3. Re: [weirds] gTLD RDAP profile meeting during IETF94 > (Francisco Arias) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 29 Oct 2015 17:49:12 -0400 > From: Brian Mountford <mountford(a)google.com> > To: gtld-tech(a)icann.org > Subject: [gtld-tech] RDAP Questions > Message-ID: > <CALRmJyhCro= > HEU11DsQxzaZAJn30uJt5wjM_q2hJT58w2+KdXg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Is this a forum for questions about RDAP specifically (as opposed to the > ICANN profile regarding RDAP)? Or should I direct those questions > elsewhere? Thanks. > > Brian >

2 1

RDAP Questions
by Brian Mountford Oct. 29, 2015

Oct. 29, 2015

Is this a forum for questions about RDAP specifically (as opposed to the ICANN profile regarding RDAP)? Or should I direct those questions elsewhere? Thanks. Brian

2 1

RDAP Policy Questions
by Brian Mountford Oct. 27, 2015

Oct. 27, 2015

Hello all. I have some questions about the ICANN policy document, directives 1.5.16 and 2.1. I couldn't find existing answers in the archive of this list, so I thought I would ask. As a general matter, should I also ask my RDAP-only questions here (as opposed to the issues specifically related to ICANN policy)? Or is there another forum for such questions? Brian -------------------------------------------------- *1.5.16. Entities MUST use jCard [RFC7095] structured addresses.* RFC 7095 defines two different types of structured address: one with the street address lines concatenated into one string, and one with a subarray for the street address. It says: 3.3.1.3. Structured Property Values The vCard specification defines properties with structured values, for example, "GENDER" or "ADR". In vCard, a structured text value consists of one or multiple text components, delimited by the SEMICOLON character. Its equivalent in jCard is a structured property value, which is an array containing one element for each text component, with empty/missing text components represented by zero-length strings. jCard Example: ["adr", {}, "text", [ "", "", "123 Main Street", "Any Town", "CA", "91921-1234", "U.S.A." ] ] Some vCard properties, for example, ADR, also allow a structured value element that itself has multiple values. In this case, the element of the array describing the structured value is itself an array with one element for each of the component's multiple values. jCard Example: ["adr", {}, "text", [ "", "", ["My Street", "Left Side", "Second Shack"], "Hometown", "PA", "18252", "U.S.A." ] ] Which form is to be used in RDAP responses? If the first version (list of simple strings, with the street lines concatenated), what is to be done with addresses containing more than two street address lines? -------------------------------------------------- *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.* Domain and entity searches are specifically mentioned, but nameserver searches are not. Does that mean that registries need not support nameserver search? Or was that an oversight? RFC 7482 does not cover entity search by address, only by name or handle. Is ICANN requiring support for an additional way to search for entities? What would the syntax of such a search be?

3 5

2nd Call for Presentations for TechDay at ICANN Dublin
by Dr Eberhard W Lisse Oct. 16, 2015

Oct. 16, 2015

We have space for one more 20 minute presentation at Tech Day in Dublin. Please submit ideas for presentations to the list addresses where this message appears or to any of the following email addresses: el(a)lisse.na ondrej.filip(a)nic.cz greetings, el -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist (Saar) el(a)lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht, Namibia ;____/

3 4

gTLD RDAP profile meeting during IETF94
by Gustavo Lozano Oct. 16, 2015

Oct. 16, 2015

Hello, [Apologies if you receive multiple copies of this email] Are you interested in meeting during IETF94 in order to discuss the gTLD RDAP profile (see http://mm.icann.org/pipermail/gtld-tech/2015-September/000507.html)? If there is enough interest, I could request a room. Remote participation would be provided if there is interest. Regards, Gustavo

6 5

RDAP Features Missing from the Draft Profile Related to Current Policy Initiatives
by Hollenbeck, Scott Oct. 13, 2015

Oct. 13, 2015

Others have shared comments on the RDAP features described in the draft operational profile. I'd like to address features that aren't mentioned in the profile that could help address known operational issues with WHOIS. At least some of these should be given serious consideration in order to take advantage of the opportunity we have to address WHOIS issues as part of a transition to RDAP. In RFC 7482 I described a number of issues with the WHOIS protocol that RDAP was designed to address, including: o lack of standardized command structures; o lack of standardized output and error structures; o lack of support for internationalization and localization; and o lack of support for user identification, authentication, and access control. The profile addresses the need for standardized command structures, output structures, and error structures. It is incomplete in terms of support for internationalization/localization, user identification, authentication, and access control. There are a number of active WHOIS-related policy efforts that can produce RDAP implementation requirements. It's not unreasonable to require implementation changes to add new features as these efforts produce results, but I'd like to avoid having to undo or remove features driven by policies that may be in conflict with the current profile proposal. Examples: Expert Working Group on gTLD Directory Services (EWG) https://community.icann.org/pages/viewpage.action?pageId=40175189 The EWG (of which I was a member) produced a lengthy final report that includes a number of recommendations that were intended to address many of the issues associated with WHOIS. The final report included a number of recommendations focused on data privacy. As-is, the profile perpetuates the WHOIS "all data available to everyone" policy. I'd very much prefer to start with a more limited approach to data access that can be broadened as we decide how best to implement the RDAP features that provide identification, authentication, authorization, and access control security services. Thick WHOIS: http://gnso.icann.org/en/group-activities/active/thick-whois The profile describes a number of features that assume implementation of a "thick" registry. Two large top-level domain registries (.com and .net) are currently "thin" registries. There's still work to be done to determine how best to implement RDAP as the thick vs. thin policy discussion evolves. I would not want to be required to implement thick WHOIS knowing that there is a looming RDAP transition requirement. I am also a little concerned about the possibility of being required to implement thick RDAP without a thorough understanding of how it works in the evolving world of laws focused on protecting personally identifiable information (PII). It would be helpful if the profile included proposed implementation requirements for thin registries. WHOIS Policy Review Team https://community.icann.org/display/whoisreview/WHOIS+Policy+Review+Team This team published its final report in May 2012. Among other things, the recommendations documented in the report address data accuracy and internationalized domain names (IDNs) and internationalized registration data. If we assume that issues with data accuracy are at least somewhat associated with current WHOIS requirements for public disclosure of PII, it may be wise to consider inclusion of RDAP security services that can be used to protect against unauthorized disclosure of PII. Draft Final Report from the Expert Working Group on Internationalized Registration Data https://gnso.icann.org/en/issues/ird/ird-draft-final-10mar15-en.pdf The profile includes provisions for the representation of IDNs as either A-labels or U-Labels. It doesn't describe requirements to return responses containing internationalized registration data. Noting that internationalized registration data is referenced in Appendix E, it would be helpful to note that such requirements are being deferred (assuming that they are indeed being deferred and were not inadvertently omitted). Scott

1 0

Verisign Engineering Comments Re: Draft RDAP Operational Profile for gTLD Registries and Registrars
by Hollenbeck, Scott Oct. 12, 2015

Oct. 12, 2015

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.

1 0

Re: [gtld-tech] [eppext] RDAP server of the registry
by Hollenbeck, Scott Oct. 9, 2015

Oct. 9, 2015

> -----Original Message----- > From: Greg Aaron [mailto:greg@illumintel.com] > Sent: Wednesday, October 07, 2015 11:27 AM > To: 'Gustavo Lozano'; 'Patrik Wallström'; Hollenbeck, Scott > Cc: gtld-tech(a)icann.org; eppext(a)ietf.org > Subject: RE: [gtld-tech] [eppext] RDAP server of the registry > > Gustavo correctly notes some important things --ICANN has contractual > requirements that tell registries and registrars what data they MUST > deliver > (currently via the WHOIS protocol), and ICANN is now working on how > that > data should be delivered via RDAP. Whatever document is created is > going > to be binding on registries and registrars. As per the 2013 RAA, once > RDAP > spec is mature "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." The new > gTLD > registry agreements contain similar. > > RDAP's supposedly been designed to deliver what ICANN might require of > its > registrars and registries. If so, we are embarking on an exercise in > implementation in the gTLD world, with ICANN as the policy authority. > BCPs > for ccTLDs etc. might be nice, but seem like a distraction from the > immediate task at hand. Thinking about the best way to implement RDAP is no distraction. It will help reduce implementation costs *and* ensure that we deliver the best technical solutions in the long run. Remember, the agreements you mentioned above were written before the RDAP specifications were completed. There are features in RDAP that aren't mentioned in the agreements or the proposed profile. There are ongoing policy efforts in ICANN that *will* have an impact on RDAP implementers. I'm suggesting that we need to take a big picture approach before we're told to implement current WHOIS operational requirements with RDAP as a transport. That just makes RDAP part of the ongoing problems. Here's one example: data privacy. WHOIS can't do it, but RDAP can, and it's not part of the profile. Shouldn't it be part of the discussion? Why shouldn't we think about it before we perpetuate a WHOIS issue that becomes an RDAP issue? > The implementation requirements should certainly be well-thought-out, > should > receive input (and hopefully collegial buy-in) from the parties who > will > have to make it work, and should be clearly documented. As Gustavo > says, > ICANN has process to deliver that. Requiring "community consensus" > about > the contents, as Scott suggested, is a different and higher standard > from > what has been agreed to in the ICANN contracts. I'm not a lawyer, so contracts aren't my area of expertise. I do, however, know something about software engineering and the costs associated with software development. Knowing that the new gTLD RA says this: "Registry Operator shall implement a new standard supporting access to domain name registration data ... if ... its implementation is commercially reasonable in the context of the overall operation of the registry." How does one determine that which is "commercially reasonable"? We know that there are policy development efforts happening in parallel that will produce additional implementation requirements. Requirements that conflict with the profile (changes in data privacy requirements, for example) will increase implementation costs, and "commercially reasonable" becomes a point of contention. The process I've described should help mitigate that risk. It's not a higher standard, it's a method that can be used to help confirm that the "commercially reasonable" requirement has been met. Scott

2 1