Updating the RSSAC FAQ
Dear RSSAC Caucus Members, According to the RSSAC Work Plan the RSSAC should update its FAQ before December every year. <https://www.icann.org/en/system/files/files/rssac-work-plan-05feb20-en.pdf> Recently the RSSAC recieved a question via the ask-rssac@icann.org<mailto:ask-rssac@icann.org> mailing address concerning why the limit of 13 root servers had been set in the 1990s. Through researching that question with the help of input from community members we developed a new answer for this question in the RSSAC FAQ. Rather than just update that single question in the FAQ the RSSAC Admin Committee decided to use this as an opportunity to update the entire FAQ for 2020. The current FAQ: <https://www.icann.org/groups/rssac/faq> The draft new FAQ: <https://docs.google.com/document/d/13znyayqFMBXxPIRrKbhyQDk1dO7LOy9oFwedy-oj...> Please review the new Draft FAQ and provide any input by May 14th, 2020. Thanks, Andrew
This is very interesting. Thank you Andrew I regularly had the same question when I make representations on DNS and DNSSEC. So in 2015 I wrote an article (in French) to explain why we have 13 instances of root servers. ( https://ramanou.blogspot.com/2015/04/13-serveurs-racines-pour-internet.html). It's important to have an official source on this question today. Regards, Ramanou BIAOU Le jeu. 30 avr. 2020 à 14:45, Andrew McConachie <andrew.mcconachie@icann.org> a écrit :
Dear RSSAC Caucus Members,
According to the RSSAC Work Plan the RSSAC should update its FAQ before December every year. < https://www.icann.org/en/system/files/files/rssac-work-plan-05feb20-en.pdf
Recently the RSSAC recieved a question via the ask-rssac@icann.org mailing address concerning why the limit of 13 root servers had been set in the 1990s. Through researching that question with the help of input from community members we developed a new answer for this question in the RSSAC FAQ. Rather than just update that single question in the FAQ the RSSAC Admin Committee decided to use this as an opportunity to update the entire FAQ for 2020.
The current FAQ: <https://www.icann.org/groups/rssac/faq>
The draft new FAQ: < https://docs.google.com/document/d/13znyayqFMBXxPIRrKbhyQDk1dO7LOy9oFwedy-oj...
Please review the new Draft FAQ and provide any input by * May 14th, 2020.*
Thanks, Andrew
_______________________________________________ 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.
-- *--BIAOU Ramanou**--* --www.biaou.net--
"there was a common expectation that IP packets on the Internet were limited to 576 bytes.” no there was a common _requirement_ that all IPv4 hosts had to accept an IP packet up to 576 bytes iun suze RFC791: Every internet destination must be able to receive a datagram of 576 octets either in one piece or in fragments to be reassembled. "Finally, many more resolvers today are capable of falling back to TCP when they receive a truncated response over UDP” really? Where is the study that publishes this finding? thanks, Geoff
On 30 Apr 2020, at 10:44 pm, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
Dear RSSAC Caucus Members,
According to the RSSAC Work Plan the RSSAC should update its FAQ before December every year. <https://www.icann.org/en/system/files/files/rssac-work-plan-05feb20-en.pdf>
Recently the RSSAC recieved a question via the ask-rssac@icann.org mailing address concerning why the limit of 13 root servers had been set in the 1990s. Through researching that question with the help of input from community members we developed a new answer for this question in the RSSAC FAQ. Rather than just update that single question in the FAQ the RSSAC Admin Committee decided to use this as an opportunity to update the entire FAQ for 2020.
The current FAQ: <https://www.icann.org/groups/rssac/faq>
The draft new FAQ: <https://docs.google.com/document/d/13znyayqFMBXxPIRrKbhyQDk1dO7LOy9oFwedy-oj...>
Please review the new Draft FAQ and provide any input by May 14th, 2020.
Thanks, Andrew
_______________________________________________ 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.
Geoff Huston writes:
"Finally, many more resolvers today are capable of falling back to TCP when they receive a truncated response over UDP”
really? Where is the study that publishes this finding?
It could use clarification, certainly, beyond just the fuzziness of "many more". There are several metrics which could all claim to be relevant. A few of them seem like they are probably true in raw numbers if only because of overall growth over the past couple of decades (and yes, good measurement would confirm that). Like: * Total number of implementations * Total number of running servers * Total number of people served (not strictly a resolver, but still relevant) But, maybe that picture changes when you ask about the percent of the whole, and then "many more" might not apply. Measurement rules, for sure. I also don't think it is entirely out of place to make a qualified claim based on our cumulative anecdotal experience that overall the TCP fallback scenario is improved now vs the past, as long as it clear that it is supposition rather than data.
On 2 May 2020, at 1:25 am, Dave Lawrence <tale@dd.org> wrote:
Geoff Huston writes:
"Finally, many more resolvers today are capable of falling back to TCP when they receive a truncated response over UDP”
really? Where is the study that publishes this finding?
It could use clarification, certainly, beyond just the fuzziness of "many more". There are several metrics which could all claim to be relevant. A few of them seem like they are probably true in raw numbers if only because of overall growth over the past couple of decades (and yes, good measurement would confirm that). Like:
* Total number of implementations * Total number of running servers * Total number of people served (not strictly a resolver, but still relevant)
But, maybe that picture changes when you ask about the percent of the whole, and then "many more" might not apply.
Measurement rules, for sure. I also don't think it is entirely out of place to make a qualified claim based on our cumulative anecdotal experience that overall the TCP fallback scenario is improved now vs the past, as long as it clear that it is supposition rather than data.
My measurements of TCP use from time to time report that the relative number of users that sit behind recursive resolvers that cannot perform TCP appear to be unchanged for the 6 years that I’ve looked (from time tim time). Now there are many ways of reporting DNS (resolvers, users, queries, … as well as absolute numbers or relative numbers). Therefore I don't understand the basis of the TCP claim in that report - it seems apocryphal to me Geoff
Question: I understood the statement to be that *resolvers* could fall back to TCP, not that the universe behind solvers could. Which is it?
On May 1, 2020, at 1:22 PM, Geoff Huston <gih@apnic.net> wrote:
On 2 May 2020, at 1:25 am, Dave Lawrence <tale@dd.org> wrote:
Geoff Huston writes:
"Finally, many more resolvers today are capable of falling back to TCP when they receive a truncated response over UDP”
really? Where is the study that publishes this finding?
It could use clarification, certainly, beyond just the fuzziness of "many more". There are several metrics which could all claim to be relevant. A few of them seem like they are probably true in raw numbers if only because of overall growth over the past couple of decades (and yes, good measurement would confirm that). Like:
* Total number of implementations * Total number of running servers * Total number of people served (not strictly a resolver, but still relevant)
But, maybe that picture changes when you ask about the percent of the whole, and then "many more" might not apply.
Measurement rules, for sure. I also don't think it is entirely out of place to make a qualified claim based on our cumulative anecdotal experience that overall the TCP fallback scenario is improved now vs the past, as long as it clear that it is supposition rather than data.
My measurements of TCP use from time to time report that the relative number of users that sit behind recursive resolvers that cannot perform TCP appear to be unchanged for the 6 years that I’ve looked (from time tim time). Now there are many ways of reporting DNS (resolvers, users, queries, … as well as absolute numbers or relative numbers).
Therefore I don't understand the basis of the TCP claim in that report - it seems apocryphal to me
Geoff
_______________________________________________ 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 May 1, 2020, at 22:22, Geoff Huston <gih@apnic.net> wrote:
On 2 May 2020, at 1:25 am, Dave Lawrence <tale@dd.org> wrote:
Geoff Huston writes:
"Finally, many more resolvers today are capable of falling back to TCP when they receive a truncated response over UDP”
really? Where is the study that publishes this finding?
It could use clarification, certainly, beyond just the fuzziness of "many more". There are several metrics which could all claim to be relevant. A few of them seem like they are probably true in raw numbers if only because of overall growth over the past couple of decades (and yes, good measurement would confirm that). Like:
* Total number of implementations * Total number of running servers * Total number of people served (not strictly a resolver, but still relevant)
But, maybe that picture changes when you ask about the percent of the whole, and then "many more" might not apply.
Measurement rules, for sure. I also don't think it is entirely out of place to make a qualified claim based on our cumulative anecdotal experience that overall the TCP fallback scenario is improved now vs the past, as long as it clear that it is supposition rather than data.
My measurements of TCP use from time to time report that the relative number of users that sit behind recursive resolvers that cannot perform TCP appear to be unchanged for the 6 years that I’ve looked (from time tim time). Now there are many ways of reporting DNS (resolvers, users, queries, … as well as absolute numbers or relative numbers).
Therefore I don't understand the basis of the TCP claim in that report - it seems apocryphal to me
I’ve deleted that sentence from the answer to question 1. The answer no longer makes any statements regarding how many resolvers can fallback to TCP if UDP comes back truncated. —Andrew
Dear RSSAC Caucus Members, Thanks to everyone who suggested edits in the updated RSSAC FAQ. <https://docs.google.com/document/d/13znyayqFMBXxPIRrKbhyQDk1dO7LOy9oFwedy-oj...> I don’t think I rejected any of the suggestions made. One significant change was to split up question 1.1 into two questions. The text is still the same, it’s now just under two different questions. If Caucus members have any more comments on the FAQ please get them in by Wednesday May 27. After that I will publish this to the RSSAC website. Thanks, Andrew On Apr 30, 2020, at 14:44, Andrew McConachie <andrew.mcconachie@icann.org<mailto:andrew.mcconachie@icann.org>> wrote: Dear RSSAC Caucus Members, According to the RSSAC Work Plan the RSSAC should update its FAQ before December every year. <https://www.icann.org/en/system/files/files/rssac-work-plan-05feb20-en.pdf [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_system_files_files_rssac-2Dwork-2Dplan-2D05feb20-2Den.pdf&d=DwMFAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KNEpS67O2txk54bIz-1lXP0tI5Rmtg88Ogwh6PVSGXJyTMuY0E2SHr70jrG3fGLJ&m=DEIkYn3xt84CnvTsY1XEWy4SkJT7FT7GzMCaM7oWK_E&s=EVXUsJlVYFvD3F-jgT7E-BxLlt86c0YjjzUoJENov7o&e=>> Recently the RSSAC recieved a question via the ask-rssac@icann.org<mailto:ask-rssac@icann.org> mailing address concerning why the limit of 13 root servers had been set in the 1990s. Through researching that question with the help of input from community members we developed a new answer for this question in the RSSAC FAQ. Rather than just update that single question in the FAQ the RSSAC Admin Committee decided to use this as an opportunity to update the entire FAQ for 2020. The current FAQ: <https://www.icann.org/groups/rssac/faq [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_groups_rssac_faq&d=DwMFAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KNEpS67O2txk54bIz-1lXP0tI5Rmtg88Ogwh6PVSGXJyTMuY0E2SHr70jrG3fGLJ&m=DEIkYn3xt84CnvTsY1XEWy4SkJT7FT7GzMCaM7oWK_E&s=0Cxrf72x_vBhK_wjCGuuP5nLpcwVwlAKqAX7ZjRxSZ8&e=>> The draft new FAQ: <https://docs.google.com/document/d/13znyayqFMBXxPIRrKbhyQDk1dO7LOy9oFwedy-oj... [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_13znyayqFMBXxPIRrKbhyQDk1dO7LOy9oFwedy-2Doj2gY_edit-3Fusp-3Dsharing&d=DwMFAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KNEpS67O2txk54bIz-1lXP0tI5Rmtg88Ogwh6PVSGXJyTMuY0E2SHr70jrG3fGLJ&m=DEIkYn3xt84CnvTsY1XEWy4SkJT7FT7GzMCaM7oWK_E&s=XOEzz7nKS1zSPBuLEbRIeo1KDj2fPu7TzYbRVl3agnw&e=>> Please review the new Draft FAQ and provide any input by May 14th, 2020. Thanks, Andrew _______________________________________________ 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p... ) and the website Terms of Service (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t... ). 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.
Dear RSSAC Caucus Members, Thanks everyone who provided feedback on this. The review period is now closed and the updated FAQ will be published to the RSSAC website. Thanks, Andrew On May 20, 2020, at 13:33, Andrew McConachie <andrew.mcconachie@icann.org<mailto:andrew.mcconachie@icann.org>> wrote: Dear RSSAC Caucus Members, Thanks to everyone who suggested edits in the updated RSSAC FAQ. <https://docs.google.com/document/d/13znyayqFMBXxPIRrKbhyQDk1dO7LOy9oFwedy-oj... [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_13znyayqFMBXxPIRrKbhyQDk1dO7LOy9oFwedy-2Doj2gY_edit-3Fusp-3Dsharing&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KNEpS67O2txk54bIz-1lXP0tI5Rmtg88Ogwh6PVSGXJyTMuY0E2SHr70jrG3fGLJ&m=lzrs-qYnTtZXAbyjbR6Xo46wmNEvFSkK7n7H6B554io&s=ALirOhmjXRSvshFkzmQeHyFHdtBpDK2ZvfJs03B-zuw&e=>> I don’t think I rejected any of the suggestions made. One significant change was to split up question 1.1 into two questions. The text is still the same, it’s now just under two different questions. If Caucus members have any more comments on the FAQ please get them in by Wednesday May 27. After that I will publish this to the RSSAC website. Thanks, Andrew On Apr 30, 2020, at 14:44, Andrew McConachie <andrew.mcconachie@icann.org<mailto:andrew.mcconachie@icann.org>> wrote: Dear RSSAC Caucus Members, According to the RSSAC Work Plan the RSSAC should update its FAQ before December every year. <https://www.icann.org/en/system/files/files/rssac-work-plan-05feb20-en.pdf [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_system_files_files_rssac-2Dwork-2Dplan-2D05feb20-2Den.pdf&d=DwMFAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KNEpS67O2txk54bIz-1lXP0tI5Rmtg88Ogwh6PVSGXJyTMuY0E2SHr70jrG3fGLJ&m=DEIkYn3xt84CnvTsY1XEWy4SkJT7FT7GzMCaM7oWK_E&s=EVXUsJlVYFvD3F-jgT7E-BxLlt86c0YjjzUoJENov7o&e=>> Recently the RSSAC recieved a question via the ask-rssac@icann.org<mailto:ask-rssac@icann.org> mailing address concerning why the limit of 13 root servers had been set in the 1990s. Through researching that question with the help of input from community members we developed a new answer for this question in the RSSAC FAQ. Rather than just update that single question in the FAQ the RSSAC Admin Committee decided to use this as an opportunity to update the entire FAQ for 2020. The current FAQ: <https://www.icann.org/groups/rssac/faq [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_groups_rssac_faq&d=DwMFAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KNEpS67O2txk54bIz-1lXP0tI5Rmtg88Ogwh6PVSGXJyTMuY0E2SHr70jrG3fGLJ&m=DEIkYn3xt84CnvTsY1XEWy4SkJT7FT7GzMCaM7oWK_E&s=0Cxrf72x_vBhK_wjCGuuP5nLpcwVwlAKqAX7ZjRxSZ8&e=>> The draft new FAQ: <https://docs.google.com/document/d/13znyayqFMBXxPIRrKbhyQDk1dO7LOy9oFwedy-oj... [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_13znyayqFMBXxPIRrKbhyQDk1dO7LOy9oFwedy-2Doj2gY_edit-3Fusp-3Dsharing&d=DwMFAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KNEpS67O2txk54bIz-1lXP0tI5Rmtg88Ogwh6PVSGXJyTMuY0E2SHr70jrG3fGLJ&m=DEIkYn3xt84CnvTsY1XEWy4SkJT7FT7GzMCaM7oWK_E&s=XOEzz7nKS1zSPBuLEbRIeo1KDj2fPu7TzYbRVl3agnw&e=>> Please review the new Draft FAQ and provide any input by May 14th, 2020. Thanks, Andrew _______________________________________________ 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p... ) and the website Terms of Service (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t... ). 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p... ) and the website Terms of Service (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t... ). 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.
participants (5)
-
Andrew McConachie -
Dave Lawrence -
Fred Baker -
Geoff Huston -
Ramanou S. BIAOU