[RSSAC Caucus] From Jeff - Messaging Workshop: Explaining the Root Server System

[David Conrad]

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 at 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-zPqDwbcDfQyP8J05n1VBNSLDjDo691ro/edit?usp=sharing
> 
> 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 at 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 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/20240609/808ca395/attachment.html>