[Ssr2-review] SSR2 Volunteer Needed

k claffy kc at caida.org
Tue Dec 31 06:53:15 UTC 2019


Russ

sorry, I had forgotten to log i to google docs so i saw some
mysterious other version of the document.

here is the text i see when i log in; it ends mid-sentence
so perhaps whoever wrote it could clarify what they meant.:

	Access to key data, for example CZDS, are not functional. At the
	moment, registries do not grant access as intended and revoke
	access periodically with long renewal processes. As these data
	are regularly used for studying abuse in the DNS, the ICANN
	community and ICANN org should take steps to ensure that access
	to CZDS as well as other data is granted, in a timely manner,
	and without unnecessary hurdles to requesters, neither being .

I guess my reaction to this is that we should not generally
say "key data, for example" -- we need to be explicit about
what data we consider important and why otherwise, how does
ICANN (or SSR3) know that the recommendation is implemented?

And even for CZDS, how will its implementation be measured?  

A related question is how is this recommendation differ from
the four recommendations on page 12 of 
https://www.icann.org/en/system/files/files/sac-097-en.pdf ?
Since SSAC wrote an entire advisory dedicated to the issue of
CZDS data access, should we not just refer to and re-recommend
these actions?  Does the SSR2 team think implementation of the
recs in SAC97 would cover what is intended by these recommendation?
If so, I think it is important to clarify that we are not
recommending anything new, but that SSAC recommendations 
are being ignored.  Or maybe they are not being ignored,
can we find out what is the status of implementation of
these SSAC recommendations, and revise our SSR2 recommendation
accordingly?

Finally, what "other data" is intended by the author of 
this text?  I think we should be explicit and not expect
ICANN to figure it out. 

k



On Mon, Dec 30, 2019 at 10:08:36PM -0800, k claffy wrote:
 > 
 > Russ
 > 
 > I will try to do this by my deadline tomorrow,
 > but I don't see a "Data Access" section on page 46,
 > nor on page 30 of a spreadsheet. 
 > 
 > I see a line "Recommendation: Data Access" on page 51
 > of the second URL below, but there is no text in that
 > section.  Am I reviewing text, or generating it?
 > If I'm generating, what Data is the "Data Access" 
 > referring to?  The Measurement Data in the previous 
 > recommendation, or something else?  Are you wanting
 > me to propose some policy for data access?
 > 
 > The request below says "The review neesd to be 
 > complete by the end of the year", so I assume I'm
 > reviewing text, but I need a pointer to where
 > the text is..
 > 
 > k
 > 
 > 
 > On Wed, Dec 18, 2019 at 01:56:03PM -0500, Russ Housley wrote:
 >  > All:
 >  > 
 >  > On the call earlier today, we assigned review for several sections of the DRAFT Report.  See:
 >  > 
 >  > 	https://docs.google.com/spreadsheets/d/1Wkodgk-MqpaoGVO3ll3RJIk8oIdxG_wPL8OyEh_boyQ/edit#gid=909846481
 >  > 
 >  > A volunteer is needed for the data access section (page 46), which is on row 30 of the spreadsheet.
 >  > 
 >  > The DRAFT Report is in this Google Doc:
 >  > 
 >  > 	https://docs.google.com/document/d/1PAG8kh4Jg_6BNMbkqebVpyqebw5mPjXr3ie-4rg210w/edit
 >  > 
 >  > This review needs to be complete this before the end of the year.
 >  > 
 >  > Who can do this one for us?
 >  > 
 >  > Thanks,
 >  >  Russ
 >  > 
 >  > _______________________________________________
 >  > 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.
 >  > 


More information about the Ssr2-review mailing list