I support this change. This would also leave bullet #2 in section 4 as ‘overcome-by-events’. For reference, ARL (h-root) currently answers this question in a very vague way, only mentioning which resolver package we use and OS/software choices that “…follow best practices for secure systems”. I would also be agreeable to the *RSS* publishing an aggregate of OS, resolver software, etc (see list from section 3.6) from all RSOs. This was mentioned on the call yesterday. The mechanics of that aggregation/publication might fall to root-ops or RSS GS and probably does not belong in this document. -Ken From: rssac-caucus <rssac-caucus-bounces@icann.org> on behalf of Lars-Johan Liman <liman@netnod.se> Date: Friday, April 7, 2023 at 4:52 AM To: RSSAC Caucus <rssac-caucus@icann.org> Subject: [URL Verdict: Neutral][Non-DoD Source] [RSSAC Caucus] Suggested change to RSSAC001v2: publish -> share. Hi! Late to the game, as always (sorry!), I've found a passage in RSSAC001v2 which I thought the WP already had handled, as it was discussed prior to establishing the WP. To me it's a reminiscence from the past that has turned into a warning light. It's the text about "to publish ... implementation details". While that might have been acceptable for systems in the role of critical infrastructure on the Internet 20 years ago, I would strongly argue that that is no longer the case. With the constant onslaught of attacks that we see on today's internet, divulging implementation details publically must be seen as rather bad advice. Security is paramount for the root server system and all other critical infrastructure systems. That said, diversity within the RSS is an important property of the system, and at least the RSOs must be able to collaborate around implementations to ensure some degree of diversity. Therefore I suggest changing the text of [E.3.6-A] to read as follows: CURRENT (OLD): [E.3.6-A] Each RSO is expected to publish documentation that describes key implementation choices to allow interested members of the Internet community to assess the diversity of implementation choices across the RSS as a whole. SUGGESTED (NEW): [E.3.6-A] In order to facilitate diversity within the RSS, each RSO is expected to share, under non-disclosure agreement, with the other RSOs, details that describe key implementation choices. The explanatory text underneath still works, I believe. Note that the suggested text in no way prevents an RSO from sharing implementation details regarding its own installation with anyone it sees fit, but and RSO is expected to share such details with _at_least_ the other RSOs. Best regards, /Liman -- #---------------------------------------------------------------------- # Lars-Johan Liman, M.Sc. ! E-mail: liman@netnod.se # Senior Systems Specialist ! Tel: +46 8 - 562 860 12 # Netnod AB, Stockholm ! http://www.netnod.se/ #---------------------------------------------------------------------- _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus _______________________________________________ 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.