[RSSAC Caucus] RSSAC Caucus Future Work Items

[Robert Carolina]

Perhaps we could look down the other end of the telescope.

I'm wondering: how do we know that the RSOs are sufficiently technologically heterogenous? Perhaps the session could simply discuss differing approaches to these types of issues, highlight plusses and minuses, and continue to encourage diverse implementations. There would be no "mandate" to adopt solutions and no need to identify anything as "best." 

Just a thought.

Kind regards

Rob

--
Robert Carolina
General Counsel
Internet Systems Consortium
+447712007095 (mobile, WhatsApp, Signal)
rob at isc.org
My normal time zone: GMT/GMT+1
LinkedIn:
www.linkedin.com/in/robertcarolina/

ISC and Internet Systems Consortium are names used by Internet Systems Consortium, Inc (a not-for-profit company) and its wholly owned subsidiary Internet Systems Corporation, both incorporated in Delaware with headquarters in New Hampshire, USA.

This transmission (the email and all attachments) is intended solely for the addressee(s). The contents are confidential and may be legally privileged. If you are not the intended addressee, or if this transmission has been addressed to you in error, you must not disclose, reproduce, or use the transmission or read any attachment. Delivery of this transmission to any person other than the intended recipient(s) does not waive privilege or confidentiality. If you have received this transmission in error, please reply by e-mail to explain receipt in error and then delete.

> On 10 Dec 2021, at 12:38, Baojun Liu <bjliu0 at gmail.com> wrote:
> 
> I couldn't agree more with Paul's point. 
> How to host a root server instance is outside the scope of RSSAC.
> Pre-RSOs should have independent rights to choose their DNS implementation, operating system and physical server. In addition, I believe that BGP routing policies are much more complex in the real world. 
> From a diversity perspective, perhaps, it is not a good idea to seek out best security practices for hosting root server instances.
> 
> Baojun Liu.
> 
>> 2021年12月2日 上午12:36，Harish Chowdhary <intern3tgovernance at gmail.com <mailto:intern3tgovernance at gmail.com>> 写道：
>> 
>> Hi,
>> 
>> Before taking the final  decision, i hope we may do  have a broader discussion.
>> 
>> Thanks,
>> Harish Chowdhary
>> 
>> On Wed, 1 Dec, 2021, 9:24 pm Paul Hoffman, <paul.hoffman at icann.org <mailto:paul.hoffman at icann.org>> wrote:
>> On Dec 1, 2021, at 6:41 AM, Andrew McConachie <andrew.mcconachie at icann.org <mailto:andrew.mcconachie at icann.org>> wrote:
>> > One work item that came up was a suggestion from maybe two years ago that the RSSAC Caucus investigate best current practices for hosting root server instances. This work would look at requirements for hosting instances including such things as physical requirements, BGP peering, etc. It would identify requirements common to most RSOs and document best practices in an RSSAC publication. The Admin Committee felt this item is out of scope for the RSSAC Caucus to consider, primarily because this is a consideration for each RSO to make independently. However, the Admin Committee also wanted to give the Caucus a chance to respond in case others disagree.
>> 
>> Isn't the specification of instance hosting requirements per-RSO? If so, having a cross-RSO list of requirements would go against the principle of RSO independence.
>> 
>> --Paul Hoffman_______________________________________________
>> rssac-caucus mailing list
>> rssac-caucus at icann.org <mailto:rssac-caucus at icann.org>
>> https://mm.icann.org/mailman/listinfo/rssac-caucus <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 <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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.
> 
> _______________________________________________
> rssac-caucus mailing list
> 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/20211210/a67016d1/attachment-0001.html>