Updated recs: 3, 24, 25, and 26
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
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
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/10KOW2F6oqR3OdV7hfuWmnYo6gtE0d0wOZHOQzXmi... and eric's subject header which says "recs: 3,24,25,26". i see no recommendation 3. presumably eric has combined it with something but i don't know which. 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? rec 24: how does root zone data "simplify PDPs"? i'm confused. i'm not sure what "deltas of data about delegated TLDs" -- deltas of what data? to what purpose? i think 'periodic measurements and longitudinal analyses' are too vague -- ICANN Org will not know how to operationalize this. 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. 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. 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. 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.
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/10KOW2F6oqR3OdV7hfuWmnYo6gtE0d0wOZHOQzXmi...
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.
participants (3)
-
Eric Osterweil -
k claffy -
Russ Housley