I must commend your excellent effort on this slidedeck.Just a couple of observations below:Agenda/Outline:There is a need to put the outline in perspective of the 39 slides to reflect the great contentsSlide 3:IP addresses are hard to remember “because it is machine readable” or write this addition as part of the footnote/explanatory noteSlide 9:
Can also include summary on DNS-over-QUIC an approach on how computer communicates with the DNS which boost Privacy(DoQ), using fast delivery service(QUIC) making your connection smooth even in unstable Internet connections especially for mobile devices (mostly in use nowadays) and other unstable networks.Well done.James Kunle OlorundareOn Thu, Jan 16, 2025 at 1:27 AM Warren Kumari via rssac-caucus <rssac-caucus@icann.org> wrote:_______________________________________________On Tue, Jan 14, 2025 at 3:07 PM, Andrew McConachie <rssac-caucus@icann.org> wrote:Dear RSSAC Caucus Members,
At most ICANN meetings the RSSAC gives an introductory presentation on the RSS as part of ICANN's How it Works series. The RSSAC will be giving this presentation again at ICANN 82.
In the past, reviewing the presentation prior to the meeting has been an RSSAC activity and the presentation has changed very little. For ICANN 82, the RSSAC Admin Committee thought it would be good to get feedback from the Caucus on this presentation. Especially since a good number of the people on this list have seen this presentation at least once. Are there things you would change about it?
Yes, yes there are :-)I think that this is a really important presentation. Unfortunately, I think that the current structure of the talk, and of the slide-deck is confusing, and that the audience gets lost.I was supposed to give this presentation in Istanbul, but was sufficiently unhappy with the deck (and my ability to present it well) that I asked Liman if he'd be willing to take it over.I had made a bunch of notes and suggested edits on a printed out copy of the slidedeck - but once Liman agreed, I threw away my printouts and notes.I'll try and remember what all my comments were, but my meta comment is that the slide deck feels like it is not well to the audience, and jumps around a bunch. I suspect that much of this is simply that the deck has grown organically, and is now in need of a rewrite / good scrubbing.It starts off with very introductory material, and then suddenly jumps into complicated technical bits… and only much later does it return to provide the foundational explanations needed to understand earlier bits.The bigget example of this is that it says that there are 13 Root Servers, with 13 sets of addresses… and over 1800 instances (slides 12, 14).This makes no sense… Only much later do slides 23 - 27 arrive with an explanation of Anycast — but by this point people have become lost and stopped paying attention.I suggest moving the entire Anycast section to just after Slide 8 or Slide 9 — this will significantly improve the flow and ability for the audience to follow the presentation.In addition:1: There should be slide numbers on all the slides — some have them and some don't.2: Slide 5:"IP addresses may also be shared." s/also// — "also" implies in addition to, and this statement doesn't follow anything.3: Slide 6:This says "name-to-IP Address" and gives an example. It then says "Many Other Mappings", and gives some examples. It's not clear that "name-to-IP Address" is a mapping (and the hyphenation is odd - if anything "Name to IP-Address" would made more sense). The "Many Other Mappings" examples are also really not clear. As examples:"Security" — this maps from Security to an IP? Or an IP to Security?"IPv6" — the initial thing says "Name to IP-Address", but IPv6 is an address."Reverse" — I guess that one could guess that this is "Oh, you can map from an IP to a name", but it's really not clear.This whole block is confusing.4: Slide 7:I think that this should either be animations (ick), or broken out into separate slides (something like Slides 8 - 14 on https://cdn.wkumari.dev/2024-03-ICANN79-SSAC_We_dont_need_nameservers.pdf ).I've watched this RSS Tutorial being presented a number of times, and, while the RSS presenters explain how this works, but it's clear from the faces in the audience that people are not following what is happening. By quickly flipping through slides (simulating an animation), this can be communicated at least as quickly, and much more clearly...5: Slide 11 should be broken out into multiple slides — it's currently a bit of a wall of text.6: Slide 12:The "The information served by the root servers" bullet point should be moved higher - it's more important than the fact that the RZM compiles the zone.7: Slide 12 says "over 1800 instances", but Slide 14 (and root-servers.org) both say >1900. Technically both statements are true, but it would look better if they were consistent.8: Major sections have title/section slides ("Overview of the Domain Name System", "Root Server System Today"). I think that it would be useful to have one for "Root Server System Principles" for consistency.9: Slide 17: This might be a much larger can of worms, but is "To remain a global network, the Internet requires a globally unique public namespace." really a **principle**? I agree that it is a fact, but it doesn't really align with the other principles. Flipping it to be "The Internet requires a globally unique public namespace in order to remain a global network", or even just "The Internet requires a globally unique public namespace" will make it better align with the others (and more of a stated principle).10: Slide 18:"The DNS is a hierarchy with a single globally unique root" — this sounds odd. A: Above it you say that the RSS just publishes whatever the IANA provides, and so this feels like a non sequitur and B: the fact that the DNS is a hierarchy is not a principle at all. I'd suggest just dropping this bullet, or changing it to "There is a single, globally unique root".11: Slides 18:Erm, who is this IANA of which you speak? Slides 12 says that the root zone is "Managed by ICANN, per community policy" and "Compiled & distributed by the Root Zone Maintainer to all root server operators". This is the first mention of IANA…12: Slides 20:"Most DNS queries ARE handled by a root server." vs "Most DNS queries are NOT even seen by a root server." — the "are NOT even seen by a root server" reads oddly to me. I think "Most DNS queries do NOT go to the root" (or "reach the root"). "are NOT even seen" sort of sounds like queries just float around, or that the root servers are dropping many queries, or that they are trying to spy on them, but miss them, or something…13: "Administration of the root zone is separate from service provision" - this reads strangely — perhaps "service provisioning" — but, to be honest, I'm really not sure what either the myth or reality are trying to say here.14: Slide 21:"Check your routes to instancesTypically want 3-4 nearby instances"What does this actually **mean**? I'm in Northern VA, and there are many instances "nearby" - I drive past many of them when heading to the grocery store, but my Internet connection egresses in Richmond, which is "far". I think something like "Typically want low latency (less than 150ms) to at least 3 or 4 instances." (I pulled <150ms out of thin air — most places have much much better than this, but if you are in e.g Fiji, your latency is much higher). Also, for almost everyone this really doesn't matter — 1: most networks don't run their own resolvers, 2: many networks don't have any useful control over their routing anyway, 3: the latency from the resolver to the root matters, not from the users to the root, and 4: we say that most queries don't hit the root. Yes, if you are a large network you can play TE tricks, but this feels like an instance where the advice isn't targeted to the expected audience for the presentation.15: Slide 22 is interesting, but misplaced. It should be after Slide 16, or after Slide 23, or… well, it could go in many places, but not here :-)16: Slide 31 should go after Slide 32, or before Slide 30, or after Slide 34 — where it currently is seems to break the flow. (nit) It also feels like it could do with some more formatting — the pictures are different sizes, and the text flows oddly. I would bold the titles, or the names and / or change the line spacing between peoples names and organization.17: Slide 36:"A proposed approach to governance of the RSS, including the ability to add/remove RSOs to the RSS"s/to the RSS// (its not needed, and makes the text flow oddly).18: I don't think that Slide 37 helps. It's true that these are stakeholders, but it distracts from the flow of what the GWG is / does. If you want to keep it, I'd move it to before Slide 36 and say something like "Who all are the stakeholders here".Apologies for the number of comments — I'm (of course) happy to chat and provide more detail / thoughts on any of my comments, etc.I really do think that this is a useful and important presentation, but that it has become tangled — with a bit of a polish it will be great again!Whttps://docs.google.com/presentation/d/1arBlU1OKHvx2ju-Sgw5lA-rxpmiSsURtnLL4VxTbDlI/
It's hard to annotate a Google presentation in line. If you would like to propose edits please specify the slide number and precisely what you would change in an email to this mailing list.
This review will close on January 28th. After that I'll develop a new version based on the comments received.
Thanks,
Andrew_______________________________________________
rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org_______________________________________________
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
To unsubscribe send an email to rssac-caucus-leave@icann.org
_______________________________________________
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.--_______________________________________________Kunle Olorundare (MNSE, PRINCE2)+2348036551591
rssac-caucus mailing list -- rssac-caucus@icann.org
To unsubscribe send an email to rssac-caucus-leave@icann.org
_______________________________________________
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_policy&d=DwICAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=krANNudPSfUTEf2kXiduBUqRjXhDsKNCASr1kibHLfs&m=afJybo2yikcC5qPHz8RTzX9YQil8AEfOheWrPfOox9f4bCKwPRy21HWSHEvh1e2F&s=tISW9_CyZKFmknr2Mift67uf8mwgFcn3bdvHT7AdLWc&e= ) and the website Terms of Service (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwICAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=krANNudPSfUTEf2kXiduBUqRjXhDsKNCASr1kibHLfs&m=afJybo2yikcC5qPHz8RTzX9YQil8AEfOheWrPfOox9f4bCKwPRy21HWSHEvh1e2F&s=SZMEWGEiLBadF5Qajao8WZjj3feaPzRuhTpbfPuT-ls&e= ). 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.