RSSAC Caucus Future Work Items
Dear RSSAC Caucus Members, The RSSAC Admin Committee held a discussion last week on potential future work items for the RSSAC Caucus to consider. We went over past ideas we have heard from the Caucus, and discussed if any are still outstanding and may warrant a future work party. 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. There are currently no items in the queue for future RSSAC Caucus work parties. If you have an idea for something the RSSAC Caucus should work on please send your suggestion to this list for discussion. Thanks, Andrew
On 01/12/2021 14:41, Andrew McConachie wrote:
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.
With my RSO hat on, I strongly agree - this is something each RSO handles independently and it should be out of scope of the RSSAC Caucus. Ray
On Dec 1, 2021, at 6:41 AM, Andrew McConachie <andrew.mcconachie@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
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@icann.org> wrote:
On Dec 1, 2021, at 6:41 AM, Andrew McConachie <andrew.mcconachie@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@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.
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@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@icann.org <mailto:paul.hoffman@icann.org>> wrote: On Dec 1, 2021, at 6:41 AM, Andrew McConachie <andrew.mcconachie@icann.org <mailto:andrew.mcconachie@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@icann.org <mailto:rssac-caucus@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@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.
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@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@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@gmail.com <mailto:intern3tgovernance@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@icann.org <mailto:paul.hoffman@icann.org>> wrote: On Dec 1, 2021, at 6:41 AM, Andrew McConachie <andrew.mcconachie@icann.org <mailto:andrew.mcconachie@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@icann.org <mailto:rssac-caucus@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@icann.org <mailto: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.
Probably, open source performance data set for benchmarking would be of common interest of all operators. A debate towards that might be interesting to develop concensus of future interoperability challenges. Regards, Ali Hussain On Fri, 10 Dec 2021, 6:18 pm Robert Carolina, <rob@isc.org> wrote:
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@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@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@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@icann.org> wrote:
On Dec 1, 2021, at 6:41 AM, Andrew McConachie < andrew.mcconachie@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@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.
_______________________________________________ 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.
On Dec 10, 2021, at 5:17 AM, Robert Carolina <rob@isc.org> wrote:
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."
This end of the telescope seems much better, yes. :-) Periodically surveying the RSOs with relevant questions could help the community determine if there are diversity gaps. This seems like a much better idea than trying to come up with (much less enforce) "best practices". --Paul Hoffman
On Dec 10, 2021, at 9:24 AM, Paul Hoffman <paul.hoffman@icann.org> wrote:
Periodically surveying the RSOs with relevant questions could help the community determine if there are diversity gaps. This seems like a much better idea than trying to come up with (much less enforce) "best practices".
No doubt. I can also imagine it seeming like a time sink for the RSOs.
participants (8)
-
Ali Hussain -
Andrew McConachie -
Baojun Liu -
Fred Baker -
Harish Chowdhary -
Paul Hoffman -
Ray Bellis -
Robert Carolina