KC: Re #2: We will never get done if we keep addressing new things as they come out. I think we could add a note that this happened after we were done gathering information. At some point, we need to stop considering new information, and I think that point has passed. Russ
On Aug 22, 2020, at 9:53 PM, k claffy <kc@caida.org> wrote:
Trying to catch up, I see on this call (that i missed) that Recommendation #29 was reviewed and approved. https://docs.google.com/document/d/1MJrPzXTngRCrdXLuiyPf7SeZsuPvwjjFGFoooQsT... (p68). The team generally agreed to the text, with a minor change to 29.4, which was made on the call and is reflected in the document.
when i look at the document, i see problems:
first, why is it called "Privacy and SSR Measurements" There is no measurement referred to in this recommendation. I'm confused.
(1) 29.1: Why is DOH stuck into the same recommendation as access to registration data, which has been a topic of interminable debate for decades? Access to registration data merits its own recommendation, given that we've now spent 2 years on an "EPDP" to try to make progress on this topic.
(2) Why is this recommendation not even referring to the EPDP, which has been going on for two years and its final report came out 2 days after this meeting, and SSAC has already published a quite adversarial comment on the EPDP draft report that came out back in the spring? ( SSAC is about to publish a similar comment on the final report, but we should at least have considered the SSAC comment on the draft report..)
I don't see how this recommendation can completely ignore the EPDP work.
(3) Why is this recommendation using the term WHOIS, which the community is replacing with RDAP?
(4) 29.3.2 [god help us if we end up with sub-sub-recommendation numbering!] basically says "ICANN should not break privacy law". Explain to me why this is needed? I claim ICANN is already aware they should not break the law, and already has lawyers monitoring this area.
(5) 29.3.3: develop a policy for *who* to protect PII? ICANN is not in charge of how registrars in Germany protect their PII. I don't understand this subrecommendation, what known problem it's aimed at solving, and how SSR3 will know it's been implemented.
(6) 29.3.4: We want ICANN to audit registrars around the world? Like in China, to make sure that Chinese registrars are following Chinese registrar law? I don't see this happening. I think we have to be realistic here. What problem are we trying to solve, and how will SSR3 know that progress has occurred?
(7) 29.4: What's a DPO? it's not yet been mentioned in this document. "provide guidance to managers and stakeholders" -- which managers and stakeholders? whkich "relevant technical developments". I have no idea what problem this subrecommendation is trying to solve.
there also seem to be entire paragraphs in the 'Rationale and Finding' for this recommendation that have nothing to do with privacy, but are focused rather on accuracy of WHOIS information. the text uses WHOIS and RDAP in different places without explaining why. Are we supposed to be reviewing recommendation text but not the accompanying text on Rationale and Findings?
struggling, k
_______________________________________________ Ssr2-review mailing list Ssr2-review@icann.org https://mm.icann.org/mailman/listinfo/ssr2-review
_______________________________________________ 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.