[Ssr2-review] Call summary: SSR2 Plenary - 29 July 2020

[Russ Housley]

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 at 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/1MJrPzXTngRCrdXLuiyPf7SeZsuPvwjjFGFoooQsT62U/edit#
> 	(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 at 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.