[Ssr2-review] Updated recs: 3, 24, 25, and 26

Eric Osterweil lists at osterweil.net
Sat Sep 21 18:49:48 UTC 2019


Hi kc,

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

> On Sep 21, 2019, at 2:20 PM, k claffy <kc at 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 at 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 at 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 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.
> 
> _______________________________________________
> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ssr2-review/attachments/20190921/e5209221/attachment.html>


More information about the Ssr2-review mailing list