I have been thinking about the SSR1-related discussion on the team call last week. To avoid opening the SSR1 appendix back up, I am thinking that we could change Recommendation 1 to be VERY specific. Yes, I am aware that this suggestion is at odds with the ICANN SME plea that we "over engineer" our recommendations. However, this suggestion does provide a clear way for SSR3 to measure our first recommendation. I suggest that we structure the recommendation like this: Finish implementing SSR1 recommendations by: - Rec 1: Do X - Rec 2: Do Y ... - Rec 9: See SSR2 Rec 2 - Rec 10: Do ... - Rec 11: Do ... - Rec 12: See SSR2 Rec 3 ... - Rec 20: See SSR2 Rec 4 ... - Rec 26: (No further action needed) - Rec 27: See SSR2 Rec 5 - Rec 28: Do Z This approach tells the ICANN staff what we looked for and did not find, yet it would avoid reopening the appendix. What do you think? Russ
+1 Russ, if we have the time. And that will depend on what comments are received on the draft.
On Jan 27, 2020, at 2:26 PM, Russ Housley <housley@vigilsec.com> wrote:
I have been thinking about the SSR1-related discussion on the team call last week. To avoid opening the SSR1 appendix back up, I am thinking that we could change Recommendation 1 to be VERY specific. Yes, I am aware that this suggestion is at odds with the ICANN SME plea that we "over engineer" our recommendations. However, this suggestion does provide a clear way for SSR3 to measure our first recommendation. I suggest that we structure the recommendation like this:
Finish implementing SSR1 recommendations by:
- Rec 1: Do X - Rec 2: Do Y ... - Rec 9: See SSR2 Rec 2 - Rec 10: Do ... - Rec 11: Do ... - Rec 12: See SSR2 Rec 3 ... - Rec 20: See SSR2 Rec 4 ... - Rec 26: (No further action needed) - Rec 27: See SSR2 Rec 5 - Rec 28: Do Z
This approach tells the ICANN staff what we looked for and did not find, yet it would avoid reopening the appendix. What do you think?
Russ
_______________________________________________ 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.
Hello,
On 27 Jan 2020, at 22:41, Norm Ritchie <norm@webcatcher.ca> wrote:
+1 Russ, if we have the time. And that will depend on what comments are received on the draft.
I don’t think it depends of time of comments we receipt. I tend to support Russ proposal. —Alain
On Jan 27, 2020, at 2:26 PM, Russ Housley <housley@vigilsec.com <mailto:housley@vigilsec.com>> wrote:
I have been thinking about the SSR1-related discussion on the team call last week. To avoid opening the SSR1 appendix back up, I am thinking that we could change Recommendation 1 to be VERY specific. Yes, I am aware that this suggestion is at odds with the ICANN SME plea that we "over engineer" our recommendations. However, this suggestion does provide a clear way for SSR3 to measure our first recommendation. I suggest that we structure the recommendation like this:
Finish implementing SSR1 recommendations by:
- Rec 1: Do X - Rec 2: Do Y ... - Rec 9: See SSR2 Rec 2 - Rec 10: Do ... - Rec 11: Do ... - Rec 12: See SSR2 Rec 3 ... - Rec 20: See SSR2 Rec 4 ... - Rec 26: (No further action needed) - Rec 27: See SSR2 Rec 5 - Rec 28: Do Z
This approach tells the ICANN staff what we looked for and did not find, yet it would avoid reopening the appendix. What do you think?
Russ
_______________________________________________ Ssr2-review mailing list Ssr2-review@icann.org <mailto: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.
It's too late not to re-open the appendix, as I went at it with my fine-tooth comb that transmogrified into a pitchfork. some of that text is simply indefensible and must be substantiated or removed. i put my comments in the wrong google doc (the marked up one instead of clean one) and heather offered to move them to the right place during the calm between the storms. I'm right with you that we have to pull out exactly what we recommend for all the SSR1-Incompletes, as our biggest gripe about the SSR1 recs were how un-SMART they were. we cannot follow that gripe with "btw, go finish all of them, and go look in the appendix where we hide many additional recommendations, but also generally do not provide any SMART version of what we recommend, nor even use the word "recommend". But, rather than have 27 new subrecommendations under Recommendation 1, a bunch of which just point to other Recommendations, I think we need to pull any SSR1 work out into new recommendations, or drop them. The document is just spaghetti o/w. But I am all in favor of someone else undergoing the exercise Russ suggests because it will illuminate the problem. grumpy. k On Mon, Jan 27, 2020 at 02:26:17PM -0500, Russ Housley wrote:
I have been thinking about the SSR1-related discussion on the team call last week. To avoid opening the SSR1 appendix back up, I am thinking that we could change Recommendation 1 to be VERY specific. Yes, I am aware that this suggestion is at odds with the ICANN SME plea that we "over engineer" our recommendations. However, this suggestion does provide a clear way for SSR3 to measure our first recommendation. I suggest that we structure the recommendation like this:
Finish implementing SSR1 recommendations by:
- Rec 1: Do X - Rec 2: Do Y ... - Rec 9: See SSR2 Rec 2 - Rec 10: Do ... - Rec 11: Do ... - Rec 12: See SSR2 Rec 3 ... - Rec 20: See SSR2 Rec 4 ... - Rec 26: (No further action needed) - Rec 27: See SSR2 Rec 5 - Rec 28: Do Z
This approach tells the ICANN staff what we looked for and did not find, yet it would avoid reopening the appendix. What do you think?
Russ
_______________________________________________ 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.
I think we should keep the construct we have and add implementation guidance to SSR1 recommendations found not fully implemented. Thanks. Denise Denise Michel denisemichel@fb.com On 1/27/20, 10:59 PM, "Ssr2-review on behalf of k claffy" <ssr2-review-bounces@icann.org on behalf of kc@caida.org> wrote: It's too late not to re-open the appendix, as I went at it with my fine-tooth comb that transmogrified into a pitchfork. some of that text is simply indefensible and must be substantiated or removed. i put my comments in the wrong google doc (the marked up one instead of clean one) and heather offered to move them to the right place during the calm between the storms. I'm right with you that we have to pull out exactly what we recommend for all the SSR1-Incompletes, as our biggest gripe about the SSR1 recs were how un-SMART they were. we cannot follow that gripe with "btw, go finish all of them, and go look in the appendix where we hide many additional recommendations, but also generally do not provide any SMART version of what we recommend, nor even use the word "recommend". But, rather than have 27 new subrecommendations under Recommendation 1, a bunch of which just point to other Recommendations, I think we need to pull any SSR1 work out into new recommendations, or drop them. The document is just spaghetti o/w. But I am all in favor of someone else undergoing the exercise Russ suggests because it will illuminate the problem. grumpy. k On Mon, Jan 27, 2020 at 02:26:17PM -0500, Russ Housley wrote: > > I have been thinking about the SSR1-related discussion on the team call last week. To avoid opening the SSR1 appendix back up, I am thinking that we could change Recommendation 1 to be VERY specific. Yes, I am aware that this suggestion is at odds with the ICANN SME plea that we "over engineer" our recommendations. However, this suggestion does provide a clear way for SSR3 to measure our first recommendation. I suggest that we structure the recommendation like this: > > Finish implementing SSR1 recommendations by: > > - Rec 1: Do X > - Rec 2: Do Y > ... > - Rec 9: See SSR2 Rec 2 > - Rec 10: Do ... > - Rec 11: Do ... > - Rec 12: See SSR2 Rec 3 > ... > - Rec 20: See SSR2 Rec 4 > ... > - Rec 26: (No further action needed) > - Rec 27: See SSR2 Rec 5 > - Rec 28: Do Z > > > This approach tells the ICANN staff what we looked for and did not find, yet it would avoid reopening the appendix. What do you think? > > Russ > > _______________________________________________ > Ssr2-review mailing list > Ssr2-review@icann.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li... > > _______________________________________________ > 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p... ) and the website Terms of Service (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t... ). 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://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li... _______________________________________________ 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p... ) and the website Terms of Service (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t... ). 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 (5)
-
ALAIN AINA -
Denise Michel -
k claffy -
Norm Ritchie -
Russ Housley