Le 7 avr. 2023 à 14:32, Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) via rssac-caucus <rssac-caucus@icann.org> a écrit :

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. 

A published aggregate would have value to the community, since it will demonstrate the level of diversity the RSS has. Who runs what is in my book less interesting. The document may say that the details are shared within the RSOs  (as Liman is proposing) and to whoever will create the aggregate list. The aggregate may say the general information without too much details: for example, it could list “Bind” as a DNS server without telling the exact version. 

Marc.


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