[RSSAC Caucus] [URL Verdict: Neutral][Non-DoD Source] Suggested change to RSSAC001v2: publish -> share.

[Marc Blanchet]

> Le 7 avr. 2023 à 14:32, Renard, Kenneth D CTR USARMY DEVCOM ARL (USA) via rssac-caucus <rssac-caucus at 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 at icann.org <mailto:rssac-caucus-bounces at icann.org>> on behalf of Lars-Johan Liman <liman at netnod.se <mailto:liman at netnod.se>>
> Date: Friday, April 7, 2023 at 4:52 AM
> To: RSSAC Caucus <rssac-caucus at icann.org <mailto:rssac-caucus at 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 at netnod.se <mailto:liman at netnod.se>
> # Senior Systems Specialist             !  Tel: +46 8 - 562 860 12
> # Netnod AB, Stockholm                  !  http://www.netnod.se/
> #----------------------------------------------------------------------
> _______________________________________________
> rssac-caucus mailing list
> rssac-caucus at icann.org <mailto:rssac-caucus at 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 at icann.org <mailto:rssac-caucus at 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/rssac-caucus/attachments/20230407/b655aaf6/attachment-0001.html>