my audio problems prevented me from hearing whatever Scott might have added to his question on the call today, and i won't have time to listen to that call again this week, so i'm hereby asking Scott explicitly whether we covered his concerns adequately? there is one more thing i wanted to mention but didn't want to take up more time on the call. i encourage (really, please) anyone with some time or some students to go through and analyze the public comments for this KSK roll announcement -- there are only ~22 of them) https://mm.icann.org/pipermail/comments-ksk-rollover-restart-01feb18/ and to consider the size and scope of the stakeholders who made them, and see if you come up with the same comclusion ICANN drew that there is a "preponderance of support to roll". i personally drew the opposite conclusion from the public comments. i predict that if "the wrong things go wrong", many people will go back and analyze these comments and come to a different conclusion than ICANN did. this i think is a serious SSR (and AT, and CCT, and even RDS-WHOIS!) issue: that icannORG has responsibility for evaluating feedback on its proposed policies before launching them. as an academic, this felt to me like authors submitting a paper, getting a bunch of critical feedback about the paper, and then the authors deciding whether the paper gets published. (or in ietf-land, whether a new RFC is standardized.) i think icannORG is in an untenable position here, i am not suggesting a deep dive into all the things they could have done differently for the KSK roll. but our recommendations should recognize CoIs inherent in the process of peer review of SSR issues, which i suspect it will come up as we evaluate SSR1 recommendations. i suspect several of us are already considering a recommendation that includes support for someone independent from icann determining whether icann has implemented all SSR2 recommendations. k