From Jeff - Messaging Workshop: Explaining the Root Server System
Jeff asked me to send this to the Caucus on his behalf. === FROM JEFF OSBORN === Dear RSSAC Caucus Members On Thursday June 13 at 10:45 local Kigali time, we will hold an RSSAC workshop (number 3 of 3) to discuss our "Messaging" project at ICANN 80. This is our effort to explain the Root Server System to people who work far outside the world of DNS. We hope you will be able to attend and we will welcome your feedback during and after the workshop. THE PROBLEM WE IDENTIFIED AND OUR RESPONSE Last year, we identified the need to create a better set of tools to explain the operation of the RSS to the growing list of law makers, regulators, business people, and other decision makers who take an increasing interest in our work. Most DNS explainers describe a so-called "cold start" scenario: the resolver is assumed to know nothing and its cache is empty. These materials say that the resolver starts first at the RSS, then queries the TLD authoritative server, etc, until the address is resolved. This type of description gives many people the (false) impression that the RSS is polled each and every time a query is sent to a resolver. As a result, many people (incorrectly) believe that the success of each and every click on a link depends upon an individual call to the RSS. The RSS then sounds like some sort of gate keeper standing at the entrance to the Internet. Of course we know that operational reality is very different. We decided the better way to explain the RSS is to turn this picture upside down and describe address resolution as it happens in operation. Resolvers first check their own cache for answers before asking authoritative servers. Then resolvers only call as many authoritative servers as are necessary. Viewed this way, calls to the RSS are exceedingly rare. We estimate that only 1 in 5,000 or 1 in 10,000 address queries triggers a call to the RSS. MESSAGING PROJECT DELIVERABLES There are currently two deliverables inspired by this project. The first deliverable is a 15-page document titled "Overview of the DNS and Root Server System." It is designed to explain DNS and the RSS using the approach outlined above. Our Work Group has been developing this document over the past year. This is a link to the draft we will be discussing in Kigali: https://docs.google.com/document/d/1ch3AU3jYai-zPqDwbcDfQyP8J05n1VBNSLDjDo69... The second deliverable, is a 20-30 minute talk with slides that summarises the main points of the explainer document. I have now delivered previews of this talk to various "pre-launch" audiences in the ICANN community. Their feedback has influenced revisions to the talk and to the explainer document. I look forward to seeing many of you in Kigali next week. Sincerely Jeff Osborn === END === -- Robert Carolina General Counsel Internet Systems Consortium rob@isc.org My normal time zone: UTC+0/UTC+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.
Hi Robert, In a quick scan of the document during a layover at the 10th circle of Hell (aka Heathrow) and during a stay in Purgatory (i.e., an observer at the HLGM), my high level takeaway was: a) it’s unclear what the goal of this document is — in my experience, most decision makers do not want to know about the details of DNS resolution, rather they want to know why they don’t need to care. b) if the target is non-technical decision makers, again based on my experience, the document is WAY, WAY too technical (e.g., very few non-technical people are going to understand what a “namespace” is and referring to RFCs is unlikely to help — they’ll simply abandon the doc), and is far, far too long. c) section 4.2 is confusing d) section 5 misrepresents parties and their relationships. e) perhaps a stylistic nit, but I personally think that generally, the long, explanatory footnotes would probably be better incorporated into main body of text. The focus on showing how the RSS is not queried that often is an interesting approach worth exploring. However, it feels like it complicates trying to explain the RSS in a way that non-technical decision makers will understand. Due to conflicts, I’m not sure I’ll be at the RSSAC working session. I provided a number of comments and a few edits in suggest mode. Feel free to use/discard as you see fit. Regards, -drc
On Jun 6, 2024, at 11:27 PM, Robert Carolina <rob@isc.org> wrote:
Jeff asked me to send this to the Caucus on his behalf.
=== FROM JEFF OSBORN ===
Dear RSSAC Caucus Members
On Thursday June 13 at 10:45 local Kigali time, we will hold an RSSAC workshop (number 3 of 3) to discuss our "Messaging" project at ICANN 80.
This is our effort to explain the Root Server System to people who work far outside the world of DNS. We hope you will be able to attend and we will welcome your feedback during and after the workshop.
THE PROBLEM WE IDENTIFIED AND OUR RESPONSE
Last year, we identified the need to create a better set of tools to explain the operation of the RSS to the growing list of law makers, regulators, business people, and other decision makers who take an increasing interest in our work.
Most DNS explainers describe a so-called "cold start" scenario: the resolver is assumed to know nothing and its cache is empty. These materials say that the resolver starts first at the RSS, then queries the TLD authoritative server, etc, until the address is resolved.
This type of description gives many people the (false) impression that the RSS is polled each and every time a query is sent to a resolver. As a result, many people (incorrectly) believe that the success of each and every click on a link depends upon an individual call to the RSS. The RSS then sounds like some sort of gate keeper standing at the entrance to the Internet.
Of course we know that operational reality is very different.
We decided the better way to explain the RSS is to turn this picture upside down and describe address resolution as it happens in operation. Resolvers first check their own cache for answers before asking authoritative servers. Then resolvers only call as many authoritative servers as are necessary. Viewed this way, calls to the RSS are exceedingly rare. We estimate that only 1 in 5,000 or 1 in 10,000 address queries triggers a call to the RSS.
MESSAGING PROJECT DELIVERABLES
There are currently two deliverables inspired by this project.
The first deliverable is a 15-page document titled "Overview of the DNS and Root Server System." It is designed to explain DNS and the RSS using the approach outlined above. Our Work Group has been developing this document over the past year. This is a link to the draft we will be discussing in Kigali: https://docs.google.com/document/d/1ch3AU3jYai-zPqDwbcDfQyP8J05n1VBNSLDjDo69...
The second deliverable, is a 20-30 minute talk with slides that summarises the main points of the explainer document. I have now delivered previews of this talk to various "pre-launch" audiences in the ICANN community. Their feedback has influenced revisions to the talk and to the explainer document.
I look forward to seeing many of you in Kigali next week.
Sincerely
Jeff Osborn
=== END ===
-- Robert Carolina General Counsel Internet Systems Consortium rob@isc.org My normal time zone: UTC+0/UTC+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.
_______________________________________________ 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.
team, can we review the problem statement that yielded this draft? this ITU briefing written by john klensin... https://www.itu.int/ITU-T/worksem/multilingual/papers/I-Klensin.pdf ...refers to three ISOC briefings written by daniel karrenberg... https://www.isoc.org/briefings/ ...which, aside from being hosted in The Wayback Machine for some reason, still seem accurate to me. what gaps does RSSAC hope to fill beyond re-hosting these briefing documents somewhere in icann.org or rssac.org? vixie re: David Conrad wrote on 2024-06-09 07:06:
Hi Robert,
In a quick scan of the document during a layover at the 10th circle of Hell (aka Heathrow) and during a stay in Purgatory (i.e., an observer at the HLGM), my high level takeaway was:
a) it’s unclear what the goal of this document is — in my experience, most decision makers do not want to know about the details of DNS resolution, rather they want to know why they don’t need to care. b) if the target is non-technical decision makers, again based on my experience, the document is WAY, WAY too technical (e.g., very few non-technical people are going to understand what a “namespace” is and referring to RFCs is unlikely to help — they’ll simply abandon the doc), and is far, far too long. c) section 4.2 is confusing d) section 5 misrepresents parties and their relationships. e) perhaps a stylistic nit, but I personally think that generally, the long, explanatory footnotes would probably be better incorporated into main body of text.
The focus on showing how the RSS is not queried that often is an interesting approach worth exploring. However, it feels like it complicates trying to explain the RSS in a way that non-technical decision makers will understand. Due to conflicts, I’m not sure I’ll be at the RSSAC working session. I provided a number of comments and a few edits in suggest mode. Feel free to use/discard as you see fit.
Regards, -drc
On Jun 6, 2024, at 11:27 PM, Robert Carolina <rob@isc.org> wrote:
Jeff asked me to send this to the Caucus on his behalf.
=== FROM JEFF OSBORN ===
Dear RSSAC Caucus Members
On Thursday June 13 at 10:45 local Kigali time, we will hold an RSSAC workshop (number 3 of 3) to discuss our "Messaging" project at ICANN 80.
This is our effort to explain the Root Server System to people who work far outside the world of DNS. We hope you will be able to attend and we will welcome your feedback during and after the workshop.
THE PROBLEM WE IDENTIFIED AND OUR RESPONSE
Last year, we identified the need to create a better set of tools to explain the operation of the RSS to the growing list of law makers, regulators, business people, and other decision makers who take an increasing interest in our work.
Most DNS explainers describe a so-called "cold start" scenario: the resolver is assumed to know nothing and its cache is empty. These materials say that the resolver starts first at the RSS, then queries the TLD authoritative server, etc, until the address is resolved.
This type of description gives many people the (false) impression that the RSS is polled each and every time a query is sent to a resolver. As a result, many people (incorrectly) believe that the success of each and every click on a link depends upon an individual call to the RSS. The RSS then sounds like some sort of gate keeper standing at the entrance to the Internet.
Of course we know that operational reality is very different.
We decided the better way to explain the RSS is to turn this picture upside down and describe address resolution as it happens in operation. Resolvers first check their own cache for answers before asking authoritative servers. Then resolvers only call as many authoritative servers as are necessary. Viewed this way, calls to the RSS are exceedingly rare. We estimate that only 1 in 5,000 or 1 in 10,000 address queries triggers a call to the RSS.
MESSAGING PROJECT DELIVERABLES
There are currently two deliverables inspired by this project.
The first deliverable is a 15-page document titled "Overview of the DNS and Root Server System." It is designed to explain DNS and the RSS using the approach outlined above. Our Work Group has been developing this document over the past year. This is a link to the draft we will be discussing in Kigali: https://docs.google.com/document/d/1ch3AU3jYai-zPqDwbcDfQyP8J05n1VBNSLDjDo69...
The second deliverable, is a 20-30 minute talk with slides that summarises the main points of the explainer document. I have now delivered previews of this talk to various "pre-launch" audiences in the ICANN community. Their feedback has influenced revisions to the talk and to the explainer document.
I look forward to seeing many of you in Kigali next week.
Sincerely
Jeff Osborn
=== END ===
-- Robert Carolina General Counsel Internet Systems Consortium rob@isc.org My normal time zone: UTC+0/UTC+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 headquartersin 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.
_______________________________________________ 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.
-- P Vixie
On Mon, Jun 10, 2024 at 3:00 PM Paul Vixie via rssac-caucus < rssac-caucus@icann.org> wrote:
team, can we review the problem statement that yielded this draft?
Ken's recollection of how we got here: This all came out of the idea that we (RSSAC, RSS) have a "PR problem" within the ICANN community and among some regulators. This could be generalized as a lack of understanding, and in some cases, a mis-understanding of how the RSS works, how RSOs work together, and how secure/robust the RSS actually is. We started to put together a list of important concepts about the RSS and then map those to specific audiences. We then selected a specific audience to target first: regulators or their staff that would be able to digest some technical content and help support the dialog between RSSAC/RSS/RSOs and regulators. We had a 3-page paper that conveyed the basic concepts and sacrificed some accuracy for brevity. The group then shifted focus to the misperception that all DNS queries result in an exchange with the RSS which is conveyed in the current document. This document has been presented as a 15-minute talk to several small, mostly non-technical, audiences and has been well received. This may become a numbered RSSAC document in the future, but for now it is being used to educate and initiate dialog with regulators and other non-technical audiences. (my use of the term "non-technical audiences" here is a bit overzealous. More accurately, it should be "those not intimately familiar with DNS and the RSS") -Ken
Hi Paul You mentioned that the "ISOC briefings written by daniel karrenberg... still seem accurate to me...." First, I am grateful to you for having pointed out the material written by Daniel Kaarrenberg when I asked last year (at IETF 117, San Francisco) for ANY materials that present the process of address resolution from the perspective of activities typically triggered by the end user. His essay was helpful in more ways than one. This is not a question so much about the accuracy or inaccuracy of existing DNS training materials and explainer documents. I accept that most of them (and anything from Danial Karranberg, especially) will be accurate. The gap that we are trying to fill is to create a body of explanation that can be understood and digested by various non-expert readers who need to understand both the purpose of the root server system, as well as the nature of the real-world impact that the RSS has on Internet operations. In other words, "accuracy" (on its own) is insufficient. We need a body of material that is accurate, that explains the role of the RSS in an operational (not hypothetical) setting, and that gives policy makers and decision makers (whether their background is in engineering, accounting, business, or liberal arts) sufficient resource to open a meaningful dialogue with us. In the process of making materials understandable we also find it necessary to avoid the use of some engineering terms that act as linguistic "false friends" in the world of politics and policy. https://en.wikipedia.org/wiki/False_friend As with any project designed to educate non-experts we have made knowing decisions to sacrifice completeness for the sake of simplifying some of the material. For example, we feel there is very little marginal utility in explaining glue records to policy makers - so we have not attempted to do so. "Accurate" and "understandable" are two different targets. As I see it, the world of DNS has a plentiful supply of materials that are accurate and some that are not. However, the world of DNS suffers from a shortage of materials that are sufficiently "understandable" to the layman to build a foundation for meaningful dialogue. On this latter point, we continue to gather valuable feedback from selected test audiences and we have already found significant utility using the current draft material to explain ourselves. Jeff will be discussing this when we convene the working session on Thursday morning. Kind regards Rob -- Robert Carolina General Counsel Internet Systems Consortium +447712007095 (mobile, WhatsApp, Signal) rob@isc.org My normal time zone: UTC+0/UTC+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 Jun 2024, at 21:00, Paul Vixie via rssac-caucus <rssac-caucus@icann.org> wrote:
team, can we review the problem statement that yielded this draft?
this ITU briefing written by john klensin...
https://www.itu.int/ITU-T/worksem/multilingual/papers/I-Klensin.pdf
...refers to three ISOC briefings written by daniel karrenberg...
https://www.isoc.org/briefings/
...which, aside from being hosted in The Wayback Machine for some reason, still seem accurate to me. what gaps does RSSAC hope to fill beyond re-hosting these briefing documents somewhere in icann.org <http://icann.org/> or rssac.org <http://rssac.org/>?
vixie
participants (4)
-
David Conrad -
Ken Renard -
Paul Vixie -
Robert Carolina