For your review - proposed RDRS Success Criteria
Dear All, As discussed during Monday’s meeting, the staff support team has taken the input received on the success criteria and attempted to translate these into a single set of criteria that following small team review are intended to be shared with the Council for its consideration. Apart from one suggestion that the team may want to discuss further to determine if/how it fits in (quality of requests & responses), we believe that all of the comments and suggestions are reflected in the suggested criteria and accompanying text. Please review in advance of Monday’s meeting: https://docs.google.com/document/d/1aGcf02uYXXLQCll9vVrNbMG6gY5bn37U/edit and add any comments or suggestions in the form of comments to the document. Note that the original input and comments can be found from page 3 onwards. Best regards, Caitlin & Marika
All, Thank you to Caitlin and Marika for pulling this together. I never envy the task you have of pulling together all the feedback, comments and input from a group like this and distilling it into a single coherent document, but as always you’ve done an excellent job. A couple feedback items from me ahead of Monday’s call. I like the single bullet capturing the overarching success criteria: Has the experience with the RDRS sufficiently informed the GNSO Council and ICANN Board to make a decision with regards to the SSAD recommendations? I’ve added a suggestion to change the “take a decision” to “make a decision”, which I think works a little better grammatically. I’ve been thinking of the overarching success criteria as being to “inform policy work”. The primary goal though really is to make a decision on what to do about the SSAD recommendations, so I think this wording works well. For item #5 in the criteria section: 5. Sufficient number of requests are made by requestors from the different requestor groups so that statistically significant data can be obtained; I’m a little uncomfortable with having a criteria that a sufficient number of requests made. I hope we get a statistically significant number of requests, but I’m not sure that is a necessary criteria. One of the concerns raised in the ODA was requestor demand is unknown. If we get a very low volume of requests, we would have to look into it to better understand why. If it is because we didn’t get the word out sufficiently for potential requestors to know about the system, then that would be a failure, but if volume was low simply because demand was low, then that could still be a success because we’ve obtained better data on potential usage volume. For item #6 in the criteria section: 6. Registrar and requestor user satisfaction with the service should be measured (note, this should not focus on the outcome of requests but on whether the service made it easier for users to submit requests and for registrars to process those requests). I like the idea of trying to measure user satisfaction, and further, I agree it should not be related to outcome of requests, but I’m not sure that making it “easier for users to submit requests and for registrars to process those requests”, is the goal, or what we should be measuring. I suppose from the standpoint of having a single entry point to submit requests, rather than having to track down the appropriate registrar and figure out their specific disclosure request process, it could be easier for requestors, but I’m not sure that is really the goal. I’m sure Sarah will correct me if I’m wrong, but I don’t think registrars expect this system to be any easier, and in particular, those with already existing disclosure request systems in place, this will be additional effort that I wouldn’t think will make things easier for them. Thank you all, I look forward to discussing on Monday’s call. Best, Marc From: GNSO-EPDPP2-SmallTeam <gnso-epdpp2-smallteam-bounces@icann.org> On Behalf Of Marika Konings Sent: Thursday, April 20, 2023 6:00 AM To: gnso-epdpp2-smallteam@icann.org Subject: [EXTERNAL] [GNSO-EPDPP2-SmallTeam] For your review - proposed RDRS Success Criteria Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Dear All, As discussed during Monday’s meeting, the staff support team has taken the input received on the success criteria and attempted to translate these into a single set of criteria that following small team review are intended to be shared with the Council for its consideration. Apart from one suggestion that the team may want to discuss further to determine if/how it fits in (quality of requests & responses), we believe that all of the comments and suggestions are reflected in the suggested criteria and accompanying text. Please review in advance of Monday’s meeting: https://docs.google.com/document/d/1aGcf02uYXXLQCll9vVrNbMG6gY5bn37U/edit and add any comments or suggestions in the form of comments to the document. Note that the original input and comments can be found from page 3 onwards. Best regards, Caitlin & Marika
Small team members and staff, Attached is a note on the success criteria. The main point of the note is that much more is required than taking measurements of the RDRS. Thanks, Steve On Thu, Apr 20, 2023 at 6:00 AM Marika Konings <marika.konings@icann.org> wrote:
Dear All,
As discussed during Monday’s meeting, the staff support team has taken the input received on the success criteria and attempted to translate these into a single set of criteria that following small team review are intended to be shared with the Council for its consideration. Apart from one suggestion that the team may want to discuss further to determine if/how it fits in (quality of requests & responses), we believe that all of the comments and suggestions are reflected in the suggested criteria and accompanying text.
Please review in advance of Monday’s meeting: https://docs.google.com/document/d/1aGcf02uYXXLQCll9vVrNbMG6gY5bn37U/edit and add any comments or suggestions in the form of comments to the document. Note that the original input and comments can be found from page 3 onwards.
Best regards,
Caitlin & Marika _______________________________________________ GNSO-EPDPP2-SmallTeam mailing list GNSO-EPDPP2-SmallTeam@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdpp2-smallteam
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
Folks, Thanks for responding during today's call to my question regarding the difference between a registrar responding with the name of a privacy or proxy service versus the word "redacted." I think there are still outstanding questions to be resolved. During the discussion an additional question arose in my mind, so here are the questions I'm seeking answers to. - Under what circumstances may a registrar impose a privacy or proxy service to hide the registration data? Some possible answers: 1. It's entirely up to the registrar. Different registrars may have different policies. The registrant has no say. (I doubt this is the case for any registrar, but I'm including it for completeness.) 2. A registrar may choose to impose a privacy or proxy service by default, but the registrant is informed and may choose not to have it imposed. 3. A registrar may give the registrant the choice of having the registration protected by the registrar's privacy or proxy service. - Under what circumstances will a registrar respond to a request with "redacted" versus with the name of the privacy or proxy service? - What recourse does the requester have in each case? Thanks, Steve
Hi all, To Steve’s question about circumstances, it doesn’t really matter why a domain uses a registrar’s P/P service (and at this time I don’t think there’s policy limiting those potential reasons), just that it does or does not. If the domain does use the registrar’s P/P service, then only the P/P data can be provided in response to an RDRS request. The group yesterday seemed strongly in favour of considering those to be ‘approved’ requests. The response would be to provide the P/P data (which is also available publicly), not redacted data. If the domain does not use the registrar’s P/P service, then the request goes through the registrar’s review process and the registrar determines which of the requested fields to disclose. For the non-disclosed fields, when the registrar provides the response directly to the requestor they would likely indicate which fields they are not disclosing, but I don’t think we have (or should) defined how exactly they’d do that within their own platform. Within the RDRS, the registrar would indicate which requested fields were disclosed (this is one of the rows in Yuko’s spreadsheet) as part of tracking the outcome of the request. The requestor’s recourse is not affected in either case: they can complain to ICANN if they believe ICANN Policy was not followed, or to the relevant legal authority if they think the law was not followed. Hope that helps! -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com From: Steve Crocker Sent: April 24, 2023 3:51 PM To: gnso-epdpp2-smallteam@icann.org Subject: [GNSO-EPDPP2-SmallTeam] Redaction vs privacy/proxy service Folks, Thanks for responding during today's call to my question regarding the difference between a registrar responding with the name of a privacy or proxy service versus the word "redacted." I think there are still outstanding questions to be resolved. During the discussion an additional question arose in my mind, so here are the questions I'm seeking answers to. • Under what circumstances may a registrar impose a privacy or proxy service to hide the registration data? Some possible answers: 1. It's entirely up to the registrar. Different registrars may have different policies. The registrant has no say. (I doubt this is the case for any registrar, but I'm including it for completeness.) 2. A registrar may choose to impose a privacy or proxy service by default, but the registrant is informed and may choose not to have it imposed. 3. A registrar may give the registrant the choice of having the registration protected by the registrar's privacy or proxy service. • Under what circumstances will a registrar respond to a request with "redacted" versus with the name of the privacy or proxy service? • What recourse does the requester have in each case? Thanks, Steve
Sarah, Thanks again for your response. Everyone, I'd like to push a bit further down this path. Attached is a short note attempting to sort out what the response will be according to: - whether there is a privacy/proxy service in place or whether the registrant has asked the registrar not to protect the registration, and - the status of the requester. I'd appreciate it if each of you would take a look and comment. This table does not take into account whether the registrant is a legal or a natural person, and it is not specific as to which fields would be treated in accordance with these rules. We can expand to cover these dimensions. (The tools we've been building at Edgemoor Research Institute do include these details, but I think it will be helpful to see if we can answer the questions in this very simplified model.) Thanks, Steve On Tue, Apr 25, 2023 at 8:21 AM Sarah Wyld <swyld@tucows.com> wrote:
Hi all,
To Steve’s question about circumstances, it doesn’t really matter why a domain uses a registrar’s P/P service (and at this time I don’t think there’s policy limiting those potential reasons), just that it does or does not.
If the domain does use the registrar’s P/P service, then only the P/P data can be provided in response to an RDRS request. The group yesterday seemed strongly in favour of considering those to be ‘approved’ requests. The response would be to provide the P/P data (which is also available publicly), not redacted data.
If the domain does not use the registrar’s P/P service, then the request goes through the registrar’s review process and the registrar determines which of the requested fields to disclose. For the non-disclosed fields, when the registrar provides the response directly to the requestor they would likely indicate which fields they are not disclosing, but I don’t think we have (or should) defined how exactly they’d do that within their own platform. Within the RDRS, the registrar would indicate which requested fields were disclosed (this is one of the rows in Yuko’s spreadsheet) as part of tracking the outcome of the request.
The requestor’s recourse is not affected in either case: they can complain to ICANN if they believe ICANN Policy was not followed, or to the relevant legal authority if they think the law was not followed.
Hope that helps!
--
*Sarah Wyld*, CIPP/E
Policy & Privacy Manager
Pronouns: she/they
swyld@tucows.com
*From: *Steve Crocker <steve@shinkuro.com> *Sent: *April 24, 2023 3:51 PM *To: *gnso-epdpp2-smallteam@icann.org *Subject: *[GNSO-EPDPP2-SmallTeam] Redaction vs privacy/proxy service
Folks,
Thanks for responding during today's call to my question regarding the difference between a registrar responding with the name of a privacy or proxy service versus the word "redacted." I think there are still outstanding questions to be resolved.
During the discussion an additional question arose in my mind, so here are the questions I'm seeking answers to.
- Under what circumstances may a registrar impose a privacy or proxy service to hide the registration data? Some possible answers:
1. It's entirely up to the registrar. Different registrars may have different policies. The registrant has no say. (I doubt this is the case for any registrar, but I'm including it for completeness.) 2. A registrar may choose to impose a privacy or proxy service by default, but the registrant is informed and may choose not to have it imposed. 3. A registrar may give the registrant the choice of having the registration protected by the registrar's privacy or proxy service.
- Under what circumstances will a registrar respond to a request with "redacted" versus with the name of the privacy or proxy service? - What recourse does the requester have in each case?
Thanks,
Steve
Hi Steve, I don’t think it helps us to break up the user groups like this; there's just users. Every user has to demonstrate their legal basis. We can’t predetermine what the outcome might be depending on the group a user falls into, because the specific circumstance for the disclosure request at hand plays a big part in the decision. To your chart - If the data is public then it can be accessed without the RDRS, but if an RDRS request is submitted then presumably the same data as is public will be provided. If the data is "normal" in your doc (I refer to it as “masked”), then the request will be evaluated on its merits and the data may or may not be disclosed. The category of requestor does not determine the outcome, but it is a factor. For example, you have “R” (Redacted) as the response to a Citizen, but a citizen could demonstrate legal basis and receive real data in the response. You have “A” (actual data) as the response to the other types of user, but they could fail to demonstrate legal basis and thus be denied, it depends on the case at hand. If the data is “protected” (has the Rr's P/P service) then only P/P data will be sent in response to the RDRS request. This is the same data as is available publicly. If the underlying data is required, that needs due process (warrant, subpoena, etc) and is not part of the RDRS at all. Due process requests are outside the scope of the RDRS, as is disclosure of data underlying a P/P service., I think we should document that and move on. Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com From: Steve Crocker Sent: April 26, 2023 3:00 PM To: Sarah Wyld Cc: gnso-epdpp2-smallteam@icann.org; Steve Crocker Subject: Re: [GNSO-EPDPP2-SmallTeam] Redaction vs privacy/proxy service Sarah, Thanks again for your response. Everyone, I'd like to push a bit further down this path. Attached is a short note attempting to sort out what the response will be according to: • whether there is a privacy/proxy service in place or whether the registrant has asked the registrar not to protect the registration, and • the status of the requester. I'd appreciate it if each of you would take a look and comment. This table does not take into account whether the registrant is a legal or a natural person, and it is not specific as to which fields would be treated in accordance with these rules. We can expand to cover these dimensions. (The tools we've been building at Edgemoor Research Institute do include these details, but I think it will be helpful to see if we can answer the questions in this very simplified model.) Thanks, Steve On Tue, Apr 25, 2023 at 8:21 AM Sarah Wyld <swyld@tucows.com> wrote: Hi all, To Steve’s question about circumstances, it doesn’t really matter why a domain uses a registrar’s P/P service (and at this time I don’t think there’s policy limiting those potential reasons), just that it does or does not. If the domain does use the registrar’s P/P service, then only the P/P data can be provided in response to an RDRS request. The group yesterday seemed strongly in favour of considering those to be ‘approved’ requests. The response would be to provide the P/P data (which is also available publicly), not redacted data. If the domain does not use the registrar’s P/P service, then the request goes through the registrar’s review process and the registrar determines which of the requested fields to disclose. For the non-disclosed fields, when the registrar provides the response directly to the requestor they would likely indicate which fields they are not disclosing, but I don’t think we have (or should) defined how exactly they’d do that within their own platform. Within the RDRS, the registrar would indicate which requested fields were disclosed (this is one of the rows in Yuko’s spreadsheet) as part of tracking the outcome of the request. The requestor’s recourse is not affected in either case: they can complain to ICANN if they believe ICANN Policy was not followed, or to the relevant legal authority if they think the law was not followed. Hope that helps! -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com From: Steve Crocker Sent: April 24, 2023 3:51 PM To: gnso-epdpp2-smallteam@icann.org Subject: [GNSO-EPDPP2-SmallTeam] Redaction vs privacy/proxy service Folks, Thanks for responding during today's call to my question regarding the difference between a registrar responding with the name of a privacy or proxy service versus the word "redacted." I think there are still outstanding questions to be resolved. During the discussion an additional question arose in my mind, so here are the questions I'm seeking answers to. • Under what circumstances may a registrar impose a privacy or proxy service to hide the registration data? Some possible answers: 1. It's entirely up to the registrar. Different registrars may have different policies. The registrant has no say. (I doubt this is the case for any registrar, but I'm including it for completeness.) 2. A registrar may choose to impose a privacy or proxy service by default, but the registrant is informed and may choose not to have it imposed. 3. A registrar may give the registrant the choice of having the registration protected by the registrar's privacy or proxy service. • Under what circumstances will a registrar respond to a request with "redacted" versus with the name of the privacy or proxy service? • What recourse does the requester have in each case? Thanks, Steve
Sarah, Thanks for the quick response. I understand your point that this is out of scope for the RDRS, but it seems to me it's very much in scope for the overall policy development process. Steve On Wed, Apr 26, 2023 at 3:54 PM Sarah Wyld <swyld@tucows.com> wrote:
Hi Steve,
I don’t think it helps us to break up the user groups like this; there's just users. Every user has to demonstrate their legal basis. We can’t predetermine what the outcome might be depending on the group a user falls into, because the specific circumstance for the disclosure request at hand plays a big part in the decision.
To your chart -
If the data is public then it can be accessed without the RDRS, but if an RDRS request is submitted then presumably the same data as is public will be provided.
If the data is "normal" in your doc (I refer to it as “masked”), then the request will be evaluated on its merits and the data may or may not be disclosed. The category of requestor does not determine the outcome, but it is a factor. For example, you have “R” (Redacted) as the response to a Citizen, but a citizen could demonstrate legal basis and receive real data in the response. You have “A” (actual data) as the response to the other types of user, but they could fail to demonstrate legal basis and thus be denied, it depends on the case at hand.
If the data is “protected” (has the Rr's P/P service) then only P/P data will be sent in response to the RDRS request. This is the same data as is available publicly. If the underlying data is required, that needs due process (warrant, subpoena, etc) and is not part of the RDRS at all. Due process requests are outside the scope of the RDRS, as is disclosure of data underlying a P/P service., I think we should document that and move on.
Thanks,
--
*Sarah Wyld*, CIPP/E
Policy & Privacy Manager
Pronouns: she/they
swyld@tucows.com
*From: *Steve Crocker <steve@shinkuro.com> *Sent: *April 26, 2023 3:00 PM *To: *Sarah Wyld <swyld@tucows.com> *Cc: *gnso-epdpp2-smallteam@icann.org; Steve Crocker <steve@shinkuro.com> *Subject: *Re: [GNSO-EPDPP2-SmallTeam] Redaction vs privacy/proxy service
Sarah,
Thanks again for your response.
Everyone,
I'd like to push a bit further down this path. Attached is a short note attempting to sort out what the response will be according to:
- whether there is a privacy/proxy service in place or whether the registrant has asked the registrar not to protect the registration, and - the status of the requester.
I'd appreciate it if each of you would take a look and comment. This table does not take into account whether the registrant is a legal or a natural person, and it is not specific as to which fields would be treated in accordance with these rules. We can expand to cover these dimensions. (The tools we've been building at Edgemoor Research Institute do include these details, but I think it will be helpful to see if we can answer the questions in this very simplified model.)
Thanks,
Steve
On Tue, Apr 25, 2023 at 8:21 AM Sarah Wyld <swyld@tucows.com> wrote:
Hi all,
To Steve’s question about circumstances, it doesn’t really matter why a domain uses a registrar’s P/P service (and at this time I don’t think there’s policy limiting those potential reasons), just that it does or does not.
If the domain does use the registrar’s P/P service, then only the P/P data can be provided in response to an RDRS request. The group yesterday seemed strongly in favour of considering those to be ‘approved’ requests. The response would be to provide the P/P data (which is also available publicly), not redacted data.
If the domain does not use the registrar’s P/P service, then the request goes through the registrar’s review process and the registrar determines which of the requested fields to disclose. For the non-disclosed fields, when the registrar provides the response directly to the requestor they would likely indicate which fields they are not disclosing, but I don’t think we have (or should) defined how exactly they’d do that within their own platform. Within the RDRS, the registrar would indicate which requested fields were disclosed (this is one of the rows in Yuko’s spreadsheet) as part of tracking the outcome of the request.
The requestor’s recourse is not affected in either case: they can complain to ICANN if they believe ICANN Policy was not followed, or to the relevant legal authority if they think the law was not followed.
Hope that helps!
--
*Sarah Wyld*, CIPP/E
Policy & Privacy Manager
Pronouns: she/they
swyld@tucows.com
*From: *Steve Crocker <steve@shinkuro.com> *Sent: *April 24, 2023 3:51 PM *To: *gnso-epdpp2-smallteam@icann.org *Subject: *[GNSO-EPDPP2-SmallTeam] Redaction vs privacy/proxy service
Folks,
Thanks for responding during today's call to my question regarding the difference between a registrar responding with the name of a privacy or proxy service versus the word "redacted." I think there are still outstanding questions to be resolved.
During the discussion an additional question arose in my mind, so here are the questions I'm seeking answers to.
- Under what circumstances may a registrar impose a privacy or proxy service to hide the registration data? Some possible answers:
1. It's entirely up to the registrar. Different registrars may have different policies. The registrant has no say. (I doubt this is the case for any registrar, but I'm including it for completeness.) 2. A registrar may choose to impose a privacy or proxy service by default, but the registrant is informed and may choose not to have it imposed. 3. A registrar may give the registrant the choice of having the registration protected by the registrar's privacy or proxy service.
- Under what circumstances will a registrar respond to a request with "redacted" versus with the name of the privacy or proxy service? - What recourse does the requester have in each case?
Thanks,
Steve
participants (4)
-
Anderson, Marc -
Marika Konings -
Sarah Wyld -
Steve Crocker