[TSG-Access-RD] Access Control Protocol in the Charter

Hollenbeck, Scott shollenbeck at verisign.com
Wed Dec 12 14:34:29 UTC 2018


I'd like to discuss the "Access Control Protocol" section of the draft charter a bit more...

As discussed on the 11 December call, this section presumes an operating model in which ICANN operates a centralized access interface. Queries for
"non-public" registration data are received at this interface and forwarded to registries and registrars for processing. Registries and registrars will
be the primary interface for "public" registration data. Is this correct?

If it is, I'm concerned that this model can make things more difficult for RDAP clients. They have to worry about sending two queries to two different
servers to retrieve a full response when they have no idea which elements are in the "public" data set and which elements are in the "non-public" data set. Attempts to hard-wire that knowledge into the code aren't wise, because policies change and they have to deal with differences in operating behavior for servers operated by gTLD providers, ccTLD providers, and address registry providers.

Query bootstrapping as described in RFC 7484 may be made more complicated. The Bootstrap Service Registry for Domain Name Space allows multiple URLs to be associated with a label, but it doesn't explicitly say that a client should need to query each specified URL. Section 4 of says, "The client chooses one of the base URLs from this array". An RFC-compliant client could thus miss a second server.

So, I would feel more comfortable with this section of the charter if it were focused on centralized authorization without making assumptions about
an operating model. Perhaps something like this:

Access Control Protocol
1. How could a centralized authorization interface operated by ICANN work?
2. How could access to non-public registration data be granted only to clients that are authorized by ICANN?
3. How could ICANN, in its role as the authorizing party, receive a third-party request for access to non-public registration data?
4. Categorization/prioritization of RDS data fields: Should all the fields be collected in one place? If so, should we design a protocol that allows
for the categorization of these fields and the prioritization of the request response?

Scott


More information about the TSG-Access-RD mailing list