Dear colleagues, At the Dublin ICANN meeting I made some comments at the microphone and said I'd send text. So, On Mon, Sep 28, 2015 at 11:07:09PM +0000, Francisco Arias wrote:
IETF in Yokohama. Your feedback on this early document would be greatly appreciated by 9 November 2015.
…here I am, late by only 10 days. I do apologise to all of you and especially to ICANN staff. I'd sincerely hoped that at least on the way to the IGF meeting I'd be able to do something about this, but I found I was unable. In any case, in case these comments are still useful, here they are. I understand the difficulty of specifying a profile where the possible future policy options are not known, but I believe that RDAP was designed with the goal of being able to deliver selectively any field at all depending on the identity of the querying party. Therefore, I think the profile could specify at least three roles: public1, authenticated-full, authenticated-test. RDAP services MUST provide a form of authentication service as described in RFC 7481. RDAP services MAY use any of the federated authentication models described in RFC 7481, section 3.2.1. RDAP services MUST provide differentiated access based on authorization, as described in RFC 7481, section 3.3. RDAP services MUST provide a minimum of three different authorized levels of access, called public1, authenticated-full, and authenticated-test. In the sections that follow, members appropriate to the public1 and authenticated-full roles are marked as appropriate to either or both. Any member not explicitly marked is assumed to appropriate to the authenticated-full role only The authenticated-test role is for testing, and is used to demonstrate the ability to selectively disable response for some field at test time. RDAP services MAY NOT implement additional differentiated responses based on authorization except as contemplated by ICANN policy or under agreement with ICANN under the RSEP process. Then, each member mentioned should be marked as "public1", "authenticated-full", or both. I think only the following fields are part of the public1 list: for domain objects: objectClassName ldhName unicodeName variants (all of it) nameservers publicIDs, but only when it's used for a registrar secureDNS status for nameserver objects: objectClassName ldhName unicodeName ipAddresses Nothing else goes in public1. I've called this public1 to make it clear that it is but one possible interpretation of what "public access" could be in the future; I'm not wedded to the name. Now, the final bit is to make it clear that access that is _un_authenticated will use the authenticated-full role until ICANN policy changes. The point of all this is to have differentiated role functionality sitting there and ready to go as soon as the ICANN policy changes, and to include in the RDAP deployment policy now all the mechanisms necessary to implement whatever policy the PDP comes up with. By doing it this way, the current policy can be respected while yet laying the ground for the just-launched PDP to do something sane. I hope this is useful. Apologies again for the long time to send it. If you have further questions, obviously, please don't hesitate to poke me. Best regards, A -- Andrew Sullivan Dyn asullivan@dyn.com