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-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@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.