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

Mon Jun 10 19:00:06 UTC 2024

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

-- 
P Vixie