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

k claffy kc at caida.org
Sat Sep 21 18:20:16 UTC 2019



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

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




More information about the Ssr2-review mailing list