[Ssr2-review] for SSR2 team member review and edit

[k claffy]

I'm not opposed to a public comment by SSR2, on what icann asked
for, which was feedback on the implementation of the six they
accepted.  in our case SSR-related feedback.  i assume this
should be of the form:

Recommendation 1: Our feedback on the proposed implementation 
of this recommenadtion is as follows

@@

Recommendation 17: Our feedback on the proposed implementation 
of this recommenadtion is as follows

@@

...

For example, I think it would be fair to say that the
implementation of Recommendation 1 is not meaningful without
the other specific data recommendations, and that it is
problematic for icann to punt all the specific data collection
to a "community input" and "budgets-permitting" process, which
will have the same misaligned incentives that have allowed SSR
threats to persist and escalate.

also, the implementation report refers to these in the 'dependencies' section:

	It is also important to take into account and leverage existing work
	relevant to data collection for the organization, including the 
	following: }

	 Open Data Program. The program goals are to a) increase
	 transparency and improved accessibility and availability of
	 data and b) strengthen ICANN orgs procedures, processes, and
	 standards for higher data usability and reuse. This
	program includes an existing platform for publication of data.

	 gTLD Marketplace Health Indicators. This set of statistics is
	 published on a regular basis to track the evolution of the
	domain name marketplace in areas such as robustness, stability,
	and trust. A community advisory panel is working with
	ICANN org to develop and refine these indicators.

	 Identifier Technology Health Indicators. This project involves
	 metrics to measure the health of the system of unique identifiers
	 the organization helps to coordinate. These include metrics
	 about the level of abuse in domain names, supported by the
	 Domain Abuse Activity Reporting (DAAR) project.

but I spent quite some time digging into each of these trying to
find any data that would help mitigate or prevent SSR threats,
and I could not find any.  It seems likely that any sort of data collection
not in the interest of a given party to collect and share will not be
collected and shared without threat of, or actual, government regulation.
(Or someone please suggest another example of an industry where such
data was volunteered, and we can cite that in the report.)
But these comments are more relevant to the recommendations that have 
not been accepted yet.. so i'm not sure this is appropriate.


Recommendation 17:   Well, this recommendation looks blown off. 

ICANN states they have already implemented the part of it they can
implement (via the 'publicly available WHOIS', so there is reference
to a unicorn in this implementation ;) ) ; the rest of it us up to other
parties who do not have an incentive to share the data.  ICANN says
they will do nothing else, and maybe others will if they find some
incentive to do so through some PDP.

ICANN also notes that providing the reseller field is optional in
response to queries, but does not explain why.  My assumption is that
CCT-RT does not think it should be, but ICANN should verify that.

ICANN also states that "CCT-RT's proposed success measure for this
recommendation is that it is possible for anyone to readily determine
the reseller associated with any gTLD registration." -- so I think
we can offer to efficiently perform CCT-RT2's future assessment of 
icann's implementation of this recommendation as "Not Effective."

but also, icann should say, out of their hands and in the contracted
parties' and EU governments' hands. and here we have another classic
example of misaligned incentives.  


Recommendation 21:   ICANN asks Org to "investigate potential
negative impacts on enforcement of compliance"  of actually publishing
which TLD is receiving complaints and details of such complaints 
including resolutions.  I'll note that this Recommendation was 
Priority High, meaning implementation within 18 months, and we're 13
months in, so we'll know whether icann managed to implement this
entirely incentive-misaligned recommendation before our final report.

But getting consensus on some SSR2 response would require that 
at least a few people actually read the report, and think about
the implications for SSR.. the prospect of a critical mass of
us doing that within a week given our level of participation on 
our own report indeed seems low.

m2c
k





On Wed, Oct 02, 2019 at 06:48:16AM +0300, Matogoro Jabera wrote:
 > Dear Russ,
 > 
 > I support the phrasing as it was given in our comment. If budget is the main
 > constrain then the board could approve the recommendation BUT the
 > implementation could remain pending up to next budget when fund will be made
 > available.
 > 
 > We could also give a paragraph analysing the approved, pending and rejected
 > recommendations. It could happen that the approved recommendations favour a
 > certain group at ICANN ecosystem. So it is better also to give a small
 > highlights on these.
 > 
 > 
 > Regards, Matogoro
 > 
 > On Wed, 2 Oct 2019, 01:11 Russ Housley, <housley at vigilsec.com> wrote:
 > 
 > > Denise and Matogoro:
 > >
 > > I have some concern with this one sentence:
 > >
 > > The correct response to budgetary concerns (based on past Board action)
 > > would have been for the Board to approve the recommendations and note that
 > > implementation would begin in the new fiscal year.
 > >
 > >
 > > I agree with the direction that this is going, but I think it would be
 > > better for the Board action to include the implementation of the
 > > recommendation in the proposed budget for the following fiscal year, and
 > > then have the community review process of the budget determine whether or
 > > not the necessary funds are allocated.
 > >
 > > 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.