Hi kc,

Thanks for your comments.  My thoughts on them are below:

On Sep 21, 2019, at 2:20 PM, k claffy <kc@caida.org> wrote:



Russ

Can you be specific about what recommendations
you want us to review and make sure they are in the doc?
And can folks please include the exact URL they want us
to review when they assign something?  the google doc
URL situation is out of control.

anyway, i'm looking at:
https://docs.google.com/document/d/10KOW2F6oqR3OdV7hfuWmnYo6gtE0d0wOZHOQzXmijx4/edit#

and eric's subject header which says "recs: 3,24,25,26”.

EO> That was provided to me by an earlier editing stage.


i see no recommendation 3.
presumably eric has combined it with something but
i don't know which.

EO> Ibid.


recommendation 24-26:
i still think we should remove all this "this would
address strategic objective N and strategic goals N.M, N.P, etc".
noone is going to know what all these objectives and goals are
while they're reading this paragraph. that information should
be pulled out into a matrix of recommendataions vs goals/objectives
they address. can't the tech writer start work on that already?

EO> That text was also provided by an earlier editing stage (and I presumed previous consensus).  I have no feelings for or against it, so I suggest we follow whatever the overall feeling of the team is.


rec 24: how does root zone data "simplify PDPs"? i'm confused.

EO> As above, this was text that came from some earlier discussions, and I am not clear on its origins.


i'm not sure what "deltas of data about delegated TLDs" --
deltas of what data?   to what purpose?

EO> That would be a longitudinal dataset of the root and TLD space.  It would be simple data, which anyone could track and maintain, but suggesting here that  this should fall to ICANN to curate.  As for utility, I (for one) think that could be useful to have for other possible measurements.


i think 'periodic measurements and longitudinal analyses' are
too vague -- ICANN Org will not know how to operationalize this.

EO> Fair, but we have to decide if we want to risk being too directive, or too vague.  Do we feel that we should be instructing ICANN on how to implement our recommendations, or just making recommendations?  Previously, I thought we have pivoted to the latter, no?


IANA registries "many needed parameters" -- i think this is
probably too vague too. at least, i can't tell what the
recommendation is asking for, and how SSR3 would know whether it
was implemented or effective.

EO> I’m confused about what is confusing.  The ``needed parameters'' comment is to illustrate why the IANA registries are important (not actually recommending anything), and then the recommendation is right below the text you’re talking about.  It says, 
``ICANN should create a set of measures that demonstrate the size, growth, and composition of the IANA registries, and also the global network availability of these registries.  These shall be measured, and archived (per above).
The data in these (and any other measurements) should be archived and made publicly available, along with any and all methodologies (to foster reproducibility). At the moment, no such reporting exists, denying stakeholders the possibility to assess key SSR indicators over time.''
Does that need to be cleared up or changed?


recommendation 25:  this one also looks too vague to operationalize.
what is the problem we are trying to solve?
if it is assessment of DNSSEC deployment, let's be specific
about that. if we think monitoring global availability of the
entire DNS is ICANN's responsbility, we should discuss that,
i don't think the community shares that view, and they will
consider it mission creep.  use of the term 'abuse' is going
to have to be more specific, and probably belongs in another
recommendation.

EO> This is why I had initially made several recommendations that were all specific about specific things.  I’m not sure when these were all folded together, but the only way I could see to fold different measurements together was make more general comments.  I think you’re right, that being specific about measurements is important, so I have ask the team for a call on whether to revert to more (but specific SMART) recommendations is preferable to collapsing here?


recommendation 26:  I am not sure the rollover needs a formal
process modeling language, or just a basic checklist of what
needs to be done before launch, like pilots have.  do others
have opinions on this?  i'm probably not qualified to judge.

EO> Disagree, I think it is absolutely imperative.  I think many of the problems we saw came from lack of a clear process and lack of direction on what to do when there were problems.  I fully understand the difficulties that come from formally modeling a complicated process, and that is why I think using a formal methodology/tool is critical. Happy to discuss.

Eric


k




On Wed, Sep 18, 2019 at 10:21:04AM -0400, Russ Housley wrote:
Please review the new text in these four recommendations before the call on September 25th.  Please send any comments to the mail list.

Russ


From: Eric Osterweil <lists@osterweil.net>
Subject: [Ssr2-review] Updated recs: 3, 24, 25, and 26
Date: September 11, 2019 at 3:58:12 PM EDT
To: SSR <ssr2-review@icann.org>

Hi all,

I updated these recommendations and collapsed them with the other recommendations that they were redundant with (the collapsed recs are listed next to these).

Eric


_______________________________________________
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.

_______________________________________________
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.