Draft RDAP Operational Profile for gTLD Registries and Registrars
Dear colleagues, As you may know, most gTLD registries and registrars have a provision in their respective agreements to implement RDAP. However, before requesting RDAP implementation, we would like your thoughts and inputs on which features, basic parameters, and objects will need to be implemented. We are calling this document the RDAP Operational Profile for gTLD Registries and Registrars. Attached you will find the first draft of the RDAP Operational Profile for gTLD Registries and Registrars (in Word and PDF formats). We are planning a session on the subject during both the ICANN meeting in Dublin and the IETF in Yokohama. Your feedback on this early document would be greatly appreciated by 9 November 2015. By then, we expect to have an updated document that we plan to publish for public comment around mid November. Regards, -- Francisco Arias Director, Technical Services Domain Name Services & Industry Engagement Global Domains Division ICANN
Took a look, some comments: 1.3.2 - I agree that RDAP providers have to offer https, but I don't see why they can't also offer plain http if they want. 1.4.1 - it says servers must support A-labels or U-labels, but I expect you mean they have to accept both. Do they have to accept names with a mixture of the two? 1.4.4 and 1.4.5 - this currently says that all of the JSON has to be returned as one giant line with no line breaks, which doesn't match the examples in RFC 7483 and doesn't make much sense. It it supposed to say there's no leading or trailing spaces or line breaks inside of JSON string values? 2.8.2 - says that if a service moves, the old service only needs to stay up until the IANA bootstrap http expiration. That's a week, which seems too short. Once the set of TLDs stabilizes, I expect people will refresh their bootstrap on the order of once a month. 2.8.3 - I don't understand it. Is it supposed to mean don't publish a bootstrap until the server is available on both ipv4 and ipv6? If so that seems redundant with 1.3.6. 3.1.2 - if you query a registrar for a name, it belongs to someone else, and the registrar happens to know whose it is (an affiliate with a separate RDAP server, perhaps) what's the harm in allowing a 301 to redirect there? R's, John
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
First, is it right of me to assume that commenting here is sufficient to be considered providing feedback for this: https://www.icann.org/public-comments/rdap-profile-2015-12-03-en ? I agree with the general aim and direction of this proposal. Comments in-line: On Thu, Nov 19, 2015 at 5:57 PM, Andrew Sullivan <asullivan@dyn.com> wrote:
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.
I would call these authorization profiles, not authentication profiles.
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.
I would include handle and any remarks the registrant intended for public consumption.
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.
I don't know if this is the right place, but it would be nice if something like draft-hollenbeck-weirds-rdap-openid could be implemented as well, say 6 months after it is published as an RFC. -andy
On Thu, Jan 07, 2016 at 05:21:04PM -0500, Andrew Newton wrote:
First, is it right of me to assume that commenting here is sufficient to be considered providing feedback for this: https://www.icann.org/public-comments/rdap-profile-2015-12-03-en ?
I don't think so, since that public comment explicitly said that it rejected the idea I posted. I don't think we disagree on any of the principled stuff, and I sort of threw that proposal together so doubtless it contained some gaps. I certainly didn't see anything in your comments that gave me pause. A -- Andrew Sullivan Dyn asullivan@dyn.com
Hi Andy, Defining what should or should not be shown is probably better suited for the new Policy Development Process on Next-Generation gTLD Registration Directory Service. There is a call for volunteers (and observers) at https://www.icann.org/news/announcement-2016-01-04-en Regards, -- Francisco On 1/7/16, 2:21 PM, "gtld-tech-bounces@icann.org on behalf of Andrew Newton" <gtld-tech-bounces@icann.org on behalf of andy@hxr.us> wrote:
First, is it right of me to assume that commenting here is sufficient to be considered providing feedback for this: https://www.icann.org/public-comments/rdap-profile-2015-12-03-en ?
I agree with the general aim and direction of this proposal. Comments in-line:
On Thu, Nov 19, 2015 at 5:57 PM, Andrew Sullivan <asullivan@dyn.com> wrote:
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.
I would call these authorization profiles, not authentication profiles.
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.
I would include handle and any remarks the registrant intended for public consumption.
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.
I don't know if this is the right place, but it would be nice if something like draft-hollenbeck-weirds-rdap-openid could be implemented as well, say 6 months after it is published as an RFC.
-andy
So I believe that is addressed in Andrew's proposal. What we don't want is for the PDP to make a recommendation only to have people say, "but the gTLD profile doesn't support tiered access." -andy On Thu, Jan 7, 2016 at 8:48 PM, Francisco Arias <francisco.arias@icann.org> wrote:
Hi Andy,
Defining what should or should not be shown is probably better suited for the new Policy Development Process on Next-Generation gTLD Registration Directory Service. There is a call for volunteers (and observers) at https://www.icann.org/news/announcement-2016-01-04-en
Regards,
-- Francisco
On 1/7/16, 2:21 PM, "gtld-tech-bounces@icann.org on behalf of Andrew Newton" <gtld-tech-bounces@icann.org on behalf of andy@hxr.us> wrote:
First, is it right of me to assume that commenting here is sufficient to be considered providing feedback for this: https://www.icann.org/public-comments/rdap-profile-2015-12-03-en ?
I agree with the general aim and direction of this proposal. Comments in-line:
On Thu, Nov 19, 2015 at 5:57 PM, Andrew Sullivan <asullivan@dyn.com> wrote:
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.
I would call these authorization profiles, not authentication profiles.
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.
I would include handle and any remarks the registrant intended for public consumption.
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.
I don't know if this is the right place, but it would be nice if something like draft-hollenbeck-weirds-rdap-openid could be implemented as well, say 6 months after it is published as an RFC.
-andy
Precisey. Sent from my iPhone
On 8 Jan 2016, at 18:42, Andrew Newton <andy@hxr.us> wrote:
So I believe that is addressed in Andrew's proposal.
What we don't want is for the PDP to make a recommendation only to have people say, "but the gTLD profile doesn't support tiered access."
-andy
On Thu, Jan 7, 2016 at 8:48 PM, Francisco Arias <francisco.arias@icann.org> wrote:
Hi Andy,
Defining what should or should not be shown is probably better suited for the new Policy Development Process on Next-Generation gTLD Registration Directory Service. There is a call for volunteers (and observers) at https://www.icann.org/news/announcement-2016-01-04-en
Regards,
-- Francisco
On 1/7/16, 2:21 PM, "gtld-tech-bounces@icann.org on behalf of Andrew Newton" <gtld-tech-bounces@icann.org on behalf of andy@hxr.us> wrote:
First, is it right of me to assume that commenting here is sufficient to be considered providing feedback for this: https://www.icann.org/public-comments/rdap-profile-2015-12-03-en ?
I agree with the general aim and direction of this proposal. Comments in-line:
On Thu, Nov 19, 2015 at 5:57 PM, Andrew Sullivan <asullivan@dyn.com> wrote:
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.
I would call these authorization profiles, not authentication profiles.
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.
I would include handle and any remarks the registrant intended for public consumption.
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.
I don't know if this is the right place, but it would be nice if something like draft-hollenbeck-weirds-rdap-openid could be implemented as well, say 6 months after it is published as an RFC.
-andy
I think there is perhaps a misunderstanding. The current profile proposal does support/allow for tiered access, as long as an agreement provision, waiver, or Consensus Policy supports/allows such thing (see section 1.4.11 of the proposal). -- Francisco On 1/8/16, 10:41 AM, "Andrew Newton" <andy@hxr.us> wrote:
So I believe that is addressed in Andrew's proposal.
What we don't want is for the PDP to make a recommendation only to have people say, "but the gTLD profile doesn't support tiered access."
-andy
On Thu, Jan 7, 2016 at 8:48 PM, Francisco Arias <francisco.arias@icann.org> wrote:
Hi Andy,
Defining what should or should not be shown is probably better suited for the new Policy Development Process on Next-Generation gTLD Registration Directory Service. There is a call for volunteers (and observers) at https://www.icann.org/news/announcement-2016-01-04-en
Regards,
-- Francisco
On 1/7/16, 2:21 PM, "gtld-tech-bounces@icann.org on behalf of Andrew Newton" <gtld-tech-bounces@icann.org on behalf of andy@hxr.us> wrote:
First, is it right of me to assume that commenting here is sufficient to be considered providing feedback for this: https://www.icann.org/public-comments/rdap-profile-2015-12-03-en ?
I agree with the general aim and direction of this proposal. Comments in-line:
On Thu, Nov 19, 2015 at 5:57 PM, Andrew Sullivan <asullivan@dyn.com> wrote:
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.
I would call these authorization profiles, not authentication profiles.
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.
I would include handle and any remarks the registrant intended for public consumption.
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.
I don't know if this is the right place, but it would be nice if something like draft-hollenbeck-weirds-rdap-openid could be implemented as well, say 6 months after it is published as an RFC.
-andy
-----Original Message----- From: gtld-tech-bounces@icann.org [mailto:gtld-tech-bounces@icann.org] On Behalf Of Francisco Arias Sent: Friday, January 08, 2016 6:53 PM To: Andrew Newton; Gannon, James-1 Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars
I think there is perhaps a misunderstanding. The current profile proposal does support/allow for tiered access, as long as an agreement provision, waiver, or Consensus Policy supports/allows such thing (see section 1.4.11 of the proposal).
Francisco, how many gTLDs have such provisions in place? Will those that do not be able to defer implementation until the needed "agreement provision, waiver, or Consensus Policy" terms are in place? Scott
I did not know that you agree through insinuation, nor did I knowingly agree to what you insinuated through compromise. If I consented for others to agree on my behalf, please clearly provide me with where and when. I don't remember doing so. I did not agree to what you insinuate, nor believe my consent for what was represented would be towards the greater good.
On 1/9/16, 6:40 AM, "Hollenbeck, Scott" <shollenbeck@verisign.com> wrote:
-----Original Message----- From: gtld-tech-bounces@icann.org On Behalf Of Francisco Arias Sent: Friday, January 08, 2016 6:53 PM To: Andrew Newton; Gannon, James-1 Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars
I think there is perhaps a misunderstanding. The current profile proposal does support/allow for tiered access, as long as an agreement provision, waiver, or Consensus Policy supports/allows such thing (see section 1.4.11 of the proposal).
Francisco, how many gTLDs have such provisions in place?
Scott, there are three gTLDs (.cat, .name, and .tel) with tiered-access provisions as described in the public comment landing page for the gTLD RDAP profile at https://www.icann.org/public-comments/rdap-profile-2015-12-03-en.
Will those that do not be able to defer implementation until the needed "agreement provision, waiver, or Consensus Policy" terms are in place?
I don’t understand this, could you elaborate? Regards, -- Francisco
-----Original Message----- From: Francisco Arias [mailto:francisco.arias@icann.org] Sent: Monday, January 11, 2016 5:00 PM To: Hollenbeck, Scott Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars
On 1/9/16, 6:40 AM, "Hollenbeck, Scott" <shollenbeck@verisign.com> wrote:
-----Original Message----- From: gtld-tech-bounces@icann.org On Behalf Of Francisco Arias Sent: Friday, January 08, 2016 6:53 PM To: Andrew Newton; Gannon, James-1 Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars
I think there is perhaps a misunderstanding. The current profile proposal does support/allow for tiered access, as long as an agreement provision, waiver, or Consensus Policy supports/allows such thing (see section 1.4.11 of the proposal).
Francisco, how many gTLDs have such provisions in place?
Scott, there are three gTLDs (.cat, .name, and .tel) with tiered-access provisions as described in the public comment landing page for the gTLD RDAP profile at https://www.icann.org/public-comments/rdap-profile- 2015-12-03-en.
Will those that do not be able to defer implementation until the needed "agreement provision, waiver, or Consensus Policy" terms are in place?
I don’t understand this, could you elaborate?
IANA's root zone database* currently lists 1,216 delegations. 901 of them are described as "generic", "generic-restricted", or "sponsored" top-level domains. Per the info you shared above, only 3 (0.003%) of the 901 gTLDs have an agreement that includes tiered-access provisions. The remainder (which represent a very significant majority) do not, and are thus excluded from "The current profile proposal does support/allow for tiered access" because "as long as an agreement provision, waiver, or Consensus Policy supports/allows such thing" is not met. Will gTLDs that do not currently have an agreement provision, waiver, or Consensus Policy that allows tiered access be able to defer implementation until an agreement provision, waiver, or Consensus Policy that allows tiered access is in place? Scott * https://www.iana.org/domains/root/db
On 1/12/16, 4:47 AM, "Hollenbeck, Scott" <shollenbeck@verisign.com> wrote:
IANA's root zone database* currently lists 1,216 delegations. 901 of them are described as "generic", "generic-restricted", or "sponsored" top-level domains. Per the info you shared above, only 3 (0.003%) of the 901 gTLDs have an agreement that includes tiered-access provisions. The remainder (which represent a very significant majority) do not, and are thus excluded from "The current profile proposal does support/allow for tiered access" because "as long as an agreement provision, waiver, or Consensus Policy supports/allows such thing" is not met.
Will gTLDs that do not currently have an agreement provision, waiver, or Consensus Policy that allows tiered access be able to defer implementation until an agreement provision, waiver, or Consensus Policy that allows tiered access is in place?
What implementation are you suggesting to be deferred? -- Francisco
-----Original Message----- From: Francisco Arias [mailto:francisco.arias@icann.org] Sent: Tuesday, January 12, 2016 12:38 PM To: Hollenbeck, Scott Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars
On 1/12/16, 4:47 AM, "Hollenbeck, Scott" <shollenbeck@verisign.com> wrote:
IANA's root zone database* currently lists 1,216 delegations. 901 of them are described as "generic", "generic-restricted", or "sponsored" top-level domains. Per the info you shared above, only 3 (0.003%) of the 901 gTLDs have an agreement that includes tiered-access provisions. The remainder (which represent a very significant majority) do not, and are thus excluded from "The current profile proposal does support/allow for tiered access" because "as long as an agreement provision, waiver, or Consensus Policy supports/allows such thing" is not met.
Will gTLDs that do not currently have an agreement provision, waiver, or Consensus Policy that allows tiered access be able to defer implementation until an agreement provision, waiver, or Consensus Policy that allows tiered access is in place?
What implementation are you suggesting to be deferred?
Are we talking about more than one? As I understand it, the profile has been written to describe proposed RDAP implementation requirements for gTLD registries and registrars. I'm asking if registries and registrars that wish to support tiered access will be able to defer an RDAP implementation until an agreement provision, waiver, or Consensus Policy that allows tiered access for more than 3 out of 901 gTLDs is in place. Scott
On 1/12/16, 9:59 AM, "Hollenbeck, Scott" <shollenbeck@verisign.com> wrote:
What implementation are you suggesting to be deferred?
Are we talking about more than one? As I understand it, the profile has been written to describe proposed RDAP implementation requirements for gTLD registries and registrars. I'm asking if registries and registrars that wish to support tiered access will be able to defer an RDAP implementation until an agreement provision, waiver, or Consensus Policy that allows tiered access for more than 3 out of 901 gTLDs is in place.
Just so that I understand, why would you like a registry/registrar to defer their RDAP implementation until there is a tiered access provision/policy? -- Francisco
On Wed, Jan 13, 2016 at 4:03 PM, Francisco Arias <francisco.arias@icann.org> wrote:
On 1/12/16, 9:59 AM, "Hollenbeck, Scott" <shollenbeck@verisign.com> wrote:
What implementation are you suggesting to be deferred?
Are we talking about more than one? As I understand it, the profile has been written to describe proposed RDAP implementation requirements for gTLD registries and registrars. I'm asking if registries and registrars that wish to support tiered access will be able to defer an RDAP implementation until an agreement provision, waiver, or Consensus Policy that allows tiered access for more than 3 out of 901 gTLDs is in place.
Just so that I understand, why would you like a registry/registrar to defer their RDAP implementation until there is a tiered access provision/policy?
I don't think Scott is desiring such a thing. I think he is asking if a registry or registrar can use the lack of provision, waiver, etc... as a reason not to deploy RDAP. -andy
On Wed, Jan 13, 2016 at 09:03:26PM +0000, Francisco Arias wrote:
Just so that I understand, why would you like a registry/registrar to defer their RDAP implementation until there is a tiered access provision/policy?
I won't speak for anyone else, but to me this was a primary motivator for RDAP. Having to do work on a brand new system twice because of ICANN policy/implementation mismatches seems like a needless burden on implementers. A -- Andrew Sullivan Dyn asullivan@dyn.com
Hi, Apologies for being dense, but this conversation is confusing me.
On Jan 13, 2016, at 3:34 PM, Andrew Sullivan <asullivan@dyn.com> wrote: On Wed, Jan 13, 2016 at 09:03:26PM +0000, Francisco Arias wrote:
Just so that I understand, why would you like a registry/registrar to defer their RDAP implementation until there is a tiered access provision/policy?
I won't speak for anyone else, but to me this was a primary motivator for RDAP. Having to do work on a brand new system twice because of ICANN policy/implementation mismatches seems like a needless burden on implementers.
AFAIK, ICANN's policy is: a) The proposed operational profile supports the use of tiered access (if, of course, your RDAP server has the code to do it) b) Because there has not been a consensus policy on the deployment of tiered access, if a registry wants to deploy tiered access they'll need to ask for a contractual waiver/amendment c) Registries have asked for and been granted amendments permitting/requiring tiered access without any policy process. Why would anyone have to "work on a brand new system twice"? Thanks, -drc
On Wed, Jan 13, 2016 at 05:05:11PM -0800, David Conrad wrote:
a) The proposed operational profile supports the use of tiered access (if, of course, your RDAP server has the code to do it)
Except that, if you're an operator of this code, you're not allowed to use that access unless you get a contractual waiver. So, if you're the development department responsible for this, you have three options: 1. Get legal involved. I hope I don't need to explain to anyone in the technical end of ICANN how desirable that is. 2. Build a piece of functionality and release it in the hopes that your test code actually covered everything everyone might do. 2.1. Later, when whatever new profile with the new rules is released, recall the developers to fix such bugs as show up, with possibly months or years in between when they implemented the bug and when they get to fix it. This is all assuming the same developers are available. 3. Just ignore the desired functionality until such time as the PDP (assuming it completes, which at least in this case seems possible) finishes _and_ the new profile shows up with whatever capabilities specified, and then implement that. (1), of course, is no guarantee that you won't need to do the latter half of (3) anyway, but let's pretend otherwise. (2) is the sort of thing that gets you fired as a program manager. (3) amounts to "do it twice". In contrast to all of this is the outline I sent, any variant of which would allow ICANN to specify now roughly any combination of fields as falling under some tier of differentiation. This has the conspicuous advantage that it provides running-code information to the PDP such that people there know what actually could work or not (a piece of information that, as nearly as I can tell, could benefit many PDPs). It simultaneously gives everyone experience with variable operational profiles before there is any policy requiring correct specification and implementation, which means that we can run various experiments and trials against real servers when we hear about things people want without a lot of deadline pressure. But if we're not to take that approach, why should bueinsses ever have to think about RDAP twice? It creates an implementation burden of a new protocol for practically no benefit to anyone. If mere machine-readability of output were the only desideratum, then we've already run the experiment to find out whether people want that (with IRIS), and the answer was no. The i18n goals are effectively already solved via the required web whois. What is the goal of implementing RDAP quickly without even the capability of differentiated access, except to check off a tick-box on someone's list of stuff to do? I'm myself very much in favour of RDAP implementation, but it's awful hard to justify any effort on this early requirement without any apparent benefit. I can imagine that an interpretation by ICANN that additional functionality that implemented differentiated access -- functionaliry not deemed part of the production service, but that is somehow offered alongside on a best-efforts, experimental basis, and that is not strictly part of the profile -- would go a long way to eliminating this objection. It's hard anyway to see how that would be a registry service as such, since it wouldn't affect any users who didn't want to play in the sandbox and wouldn't be necessary for anyone. The goal of early delivery of RDAP with a universal single-tier interface would be achieved, the PDP would get information probably useful to its work, and nobody would be inconvenienced since the service wouldn't actually make any promises. Best regards, A -- Andrew Sullivan Dyn asullivan@dyn.com
Well said, and spot on. +1! Many (most?) of the new gTLD registry agreements require searchable whois and such functionality is restricted to authenticated users. The RDAP profile even mentions this in 2.1 ("Registries offering searchable Whois service (e.g., per exhibit A of their RA) MUST support RDAP search requests for domains and entities.") Yet - though your proposal is mentioned - the public comments page glosses over the need for authentication saying "ICANN notes that for the three gTLDs that have differentiated access in their registry agreements, there are, at least two models." Three gTLDs? No, anyone offering searchable whois is required to do so only to authenticated users. The public comments page also says "The proposal indicated that differentiated access as described should be implemented by all, but not enabled until a contract change or a consensus policy on the subject had been put in place." Without putting words in your mouth, I don't think it said exactly that. Instead, the proposal suggested specifying three tiers in the existing RDAP profile, with varying responses, and defaulting to "authenticated-full" (i.e., unauthenticated users get authenticated responses) until ICANN policy changes. Doing so would give implementers something concrete to go on. But unless the community agrees (or ICANN dictates) how this is to be done, attempts to do so now run the significant risk of requiring potentially significant rework when an authentication/authorization profile is handed down. Ann Hammond -----Original Message----- From: Andrew Sullivan <asullivan@dyn.com> To: gtld-tech <gtld-tech@icann.org> Sent: Wed, Jan 13, 2016 9:27 pm Subject: Re: [gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars On Wed, Jan 13, 2016 at 05:05:11PM -0800, David Conrad wrote:
a) The proposed operational profile supports the use of tiered access (if, of course, your RDAP server has the code to do it)
Except that, if you're an operator of this code, you're not allowed to use that access unless you get a contractual waiver. So, if you're the development department responsible for this, you have three options: 1. Get legal involved. I hope I don't need to explain to anyone in the technical end of ICANN how desirable that is. 2. Build a piece of functionality and release it in the hopes that your test code actually covered everything everyone might do. 2.1. Later, when whatever new profile with the new rules is released, recall the developers to fix such bugs as show up, with possibly months or years in between when they implemented the bug and when they get to fix it. This is all assuming the same developers are available. 3. Just ignore the desired functionality until such time as the PDP (assuming it completes, which at least in this case seems possible) finishes _and_ the new profile shows up with whatever capabilities specified, and then implement that. (1), of course, is no guarantee that you won't need to do the latter half of (3) anyway, but let's pretend otherwise. (2) is the sort of thing that gets you fired as a program manager. (3) amounts to "do it twice". In contrast to all of this is the outline I sent, any variant of which would allow ICANN to specify now roughly any combination of fields as falling under some tier of differentiation. This has the conspicuous advantage that it provides running-code information to the PDP such that people there know what actually could work or not (a piece of information that, as nearly as I can tell, could benefit many PDPs). It simultaneously gives everyone experience with variable operational profiles before there is any policy requiring correct specification and implementation, which means that we can run various experiments and trials against real servers when we hear about things people want without a lot of deadline pressure. But if we're not to take that approach, why should bueinsses ever have to think about RDAP twice? It creates an implementation burden of a new protocol for practically no benefit to anyone. If mere machine-readability of output were the only desideratum, then we've already run the experiment to find out whether people want that (with IRIS), and the answer was no. The i18n goals are effectively already solved via the required web whois. What is the goal of implementing RDAP quickly without even the capability of differentiated access, except to check off a tick-box on someone's list of stuff to do? I'm myself very much in favour of RDAP implementation, but it's awful hard to justify any effort on this early requirement without any apparent benefit. I can imagine that an interpretation by ICANN that additional functionality that implemented differentiated access -- functionaliry not deemed part of the production service, but that is somehow offered alongside on a best-efforts, experimental basis, and that is not strictly part of the profile -- would go a long way to eliminating this objection. It's hard anyway to see how that would be a registry service as such, since it wouldn't affect any users who didn't want to play in the sandbox and wouldn't be necessary for anyone. The goal of early delivery of RDAP with a universal single-tier interface would be achieved, the PDP would get information probably useful to its work, and nobody would be inconvenienced since the service wouldn't actually make any promises. Best regards, A -- Andrew Sullivan Dyn asullivan@dyn.com
On 1/13/16, 7:57 PM, "gtld-tech-bounces@icann.org<mailto:gtld-tech-bounces@icann.org> on behalf of gtld-tech@icann.org<mailto:gtld-tech@icann.org>" <gtld-tech-bounces@icann.org<mailto:gtld-tech-bounces@icann.org> on behalf of gtld-tech@icann.org<mailto:gtld-tech@icann.org>> wrote: Well said, and spot on. +1! Many (most?) of the new gTLD registry agreements require searchable whois and such functionality is restricted to authenticated users. The RDAP profile even mentions this in 2.1 ("Registries offering searchable Whois service (e.g., per exhibit A of their RA) MUST support RDAP search requests for domains and entities.") Yet - though your proposal is mentioned - the public comments page glosses over the need for authentication saying "ICANN notes that for the three gTLDs that have differentiated access in their registry agreements, there are, at least two models." Three gTLDs? No, anyone offering searchable whois is required to do so only to authenticated users. The language about searchability in RDAP was removed in the last version of the draft profile (which is what is for public comment now) as explained in the message http://mm.icann.org/pipermail/gtld-tech/2015-December/000561.html Regards, -- Francisco
b) Because there has not been a consensus policy on the deployment of tiered access, if a registry wants to deploy tiered access they'll need to ask for a contractual waiver/amendment c) Registries have asked for and been granted amendments permitting/requiring tiered access without any policy process.
Approximately every registry and registrar appears to have tiered access to their port 43 servers, if only in ways that relax or remove rate limits. Do they all have waivers? R's, John PS: That's a real question. I have no idea.
I don't think rate limiting necessarily falls under tiered access. In this context tiered access means granting different views to different classes of users, which then requires identification of the user. I suppose one might say that a registry or registrar could have different rate limits for different IP addresses and that doing so constitutes tiered access. But I don't know of any registry doing such and think such would be discouraged, if not prohibited, by ICANN except in abuse scenarios. Ann Hammond -----Original Message----- From: John Levine <johnl@taugh.com> To: gtld-tech <gtld-tech@icann.org> Sent: Wed, Jan 13, 2016 10:19 PM Subject: Re: [gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars
b) Because there has not been a consensus policy on the deployment of tiered access, if a registry wants to deploy tiered access they'll need to ask for a contractual waiver/amendment c) Registries have asked for and been granted amendments permitting/requiring tiered access without any policy process.
Approximately every registry and registrar appears to have tiered access to their port 43 servers, if only in ways that relax or remove rate limits. Do they all have waivers? R's, John PS: That's a real question. I have no idea.
-----Original Message----- From: Francisco Arias [mailto:francisco.arias@icann.org] Sent: Wednesday, January 13, 2016 4:03 PM To: Hollenbeck, Scott Cc: gtld-tech@icann.org Subject: Re: [gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars
On 1/12/16, 9:59 AM, "Hollenbeck, Scott" <shollenbeck@verisign.com> wrote:
What implementation are you suggesting to be deferred?
Are we talking about more than one? As I understand it, the profile has been written to describe proposed RDAP implementation requirements for gTLD registries and registrars. I'm asking if registries and registrars that wish to support tiered access will be able to defer an RDAP implementation until an agreement provision, waiver, or Consensus Policy that allows tiered access for more than 3 out of 901 gTLDs is in place.
Just so that I understand, why would you like a registry/registrar to defer their RDAP implementation until there is a tiered access provision/policy?
The answer is described in this blog post: http://blogs.verisign.com/blog/entry/as_whois_transitions_to_rdap http://www.circleid.com/posts/20151123_as_whois_transitions_to_rdap_how_do_w... Summary: I'm deeply concerned that a production implementation of RDAP that is designed to provide "complete functionality equivalence with WHOIS" (quoted from the profile discussion session in Dublin) without taking advantage of the new features in RDAP is itself functionally incomplete and inadequate. I want to be able to deploy an implementation of RDAP that addresses the deficiencies of WHOIS without first having to deploy (and later replace (probably more than once) as the multitude of ICANN's WHOIS-fixing policy efforts evolve) something that is little more than JSON-encoded WHOIS. Scott
+1 Ron Geens DNS Belgium .be/.vlaanderen/.brussels On 14 Jan 2016, at 13:27, Hollenbeck, Scott <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>> wrote: -----Original Message----- From: Francisco Arias [mailto:francisco.arias@icann.org] Sent: Wednesday, January 13, 2016 4:03 PM To: Hollenbeck, Scott Cc: gtld-tech@icann.org<mailto:gtld-tech@icann.org> Subject: Re: [gtld-tech] Draft RDAP Operational Profile for gTLD Registries and Registrars On 1/12/16, 9:59 AM, "Hollenbeck, Scott" <shollenbeck@verisign.com<mailto:shollenbeck@verisign.com>> wrote: What implementation are you suggesting to be deferred? Are we talking about more than one? As I understand it, the profile has been written to describe proposed RDAP implementation requirements for gTLD registries and registrars. I'm asking if registries and registrars that wish to support tiered access will be able to defer an RDAP implementation until an agreement provision, waiver, or Consensus Policy that allows tiered access for more than 3 out of 901 gTLDs is in place. Just so that I understand, why would you like a registry/registrar to defer their RDAP implementation until there is a tiered access provision/policy? The answer is described in this blog post: http://blogs.verisign.com/blog/entry/as_whois_transitions_to_rdap http://www.circleid.com/posts/20151123_as_whois_transitions_to_rdap_how_do_w... Summary: I'm deeply concerned that a production implementation of RDAP that is designed to provide "complete functionality equivalence with WHOIS" (quoted from the profile discussion session in Dublin) without taking advantage of the new features in RDAP is itself functionally incomplete and inadequate. I want to be able to deploy an implementation of RDAP that addresses the deficiencies of WHOIS without first having to deploy (and later replace (probably more than once) as the multitude of ICANN's WHOIS-fixing policy efforts evolve) something that is little more than JSON-encoded WHOIS. Scott
participants (10)
-
Andrew Newton -
Andrew Sullivan -
David Conrad -
Francisco Arias -
Gannon, James-1 -
Hollenbeck, Scott -
John Levine -
luvingnc＠aol.com -
Ronald Geens -
Tamer Rizk