ICANN 82 RSS Tutorial - How it Works
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? https://docs.google.com/presentation/d/1arBlU1OKHvx2ju-Sgw5lA-rxpmiSsURtnLL4... 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
This is a nice set of slides. Since you asked for comments, I took a quick look. Steve Crocker ============================================================ Slide 14 gives key dates. A few other events are not root server dates per se but nonetheless seem to me useful and relevant to include. Date for DNSSEC. Among other things, DNSSEC expanded the size of the root zone quite substantially, which caused concern. Date for the introduction of IDNs Date of new gTLDs, which substantially expanded the number of TLDs ============================================================ Slide 20 on Myths is good. I recommend further emphasis in some of the comparisons. e.g. Root *servers* control where Internet traffic goes vs *Routers* control where Internet traffic goes Administration of the root zone... vs Administration is handled by *IANA*; Provisioning is handled by the *RSOs* ============================================================ Slide 22: Why the sharp drop off in queries in 2021? Was this a pandemic effect and consistent with a similar drop off in overall Internet traffic or something else? Might be worth adding a note to the slide. ============================================================ Slides 31 and 32 I'd reverse the order of these two slides. Not a big deal, just my sense of the natural order of presentation. ============================================================ That's all. Nothing critical. Thanks, Steve Crocker ============================================================ On Tue, Jan 14, 2025 at 3:07 PM Andrew McConachie via rssac-caucus < 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?
https://docs.google.com/presentation/d/1arBlU1OKHvx2ju-Sgw5lA-rxpmiSsURtnLL4...
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.
-- Sent by a Verified sender
On Jan 14, 2025, at 3:30 PM, Steve Crocker via rssac-caucus <rssac-caucus@icann.org> wrote:
============================================================
Slide 22: Why the sharp drop off in queries in 2021? Was this a pandemic effect and consistent with a similar drop off in overall Internet traffic or something else? Might be worth adding a note to the slide.
This is a reduction in what we called “chromium queries” to the root zone: https://blog.verisign.com/domain-names/chromiums-impact-on-root-dns-traffic/ https://blog.verisign.com/domain-names/chromiums-reduction-of-root-dns-traff... DW
Steve, On Jan 14, 2025, at 12:30 PM, Steve Crocker via rssac-caucus <rssac-caucus@icann.org> wrote:
Administration of the root zone... vs Administration is handled by IANA; Provisioning is handled by the RSOs
Not to be too pedantic, but I personally believe it more accurate to say: * RSOs provide the most common means by which the root zone is published. * Verisign (Root Zone Maintainer) handles provisioning. * PTI performs the IANA functions (Root Zone Manager) and thus handles administration. Regards, -drc
Hi,
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?
A few suggestions: Page 5: Many (most?) non-technical folks will: * probably associate the word “object” with a physical thing. Why not “The system that translates a name into different types of information associated with that name”? * hear the words "distributed, loosely coherent, scalable, dynamic database” as the equivalent of what technical folks would describe as "terminal noise.” Is that sentence useful? Page 8: * Non-technical folks may interpret “TLD servers” as something other than the name servers for the TLDs, perhaps "Root servers only provide information about themselves and top-level-domain (TLD) nameservers”? * Non-technical folks may interpret “records” to be something other than attributes associated with a name, perhaps “TLD information returned by root name servers have TTLs of one or two days”? Page 9: * I’m a bit unclear as to why DOH/DOT are mentioned here, since they’re unrelated to the root servers. Page 11: First bullet: * Non-technical folks may interpret “all the information necessary to contact the TLDs” to mean telephone numbers, email addresses, etc. Perhaps "It has no parent and contains only the names and addresses of the TLDs name servers”? (I know it’s not strictly accurate, but the details probably aren’t important to the How It Works crowd). Alternatively, “It has no parent and contains only the information necessary to create secure delegation of authority to the TLDs” (might be too technical)? Second bullet: * Perhaps use “publish” instead of serve? Third bullet: * Perhaps "An organization responsible for running a name server on one of the IPv4/IPv6 pairs of addresses identified as a root name server in the root zone”? Fourth bullet: * Perhaps “An RSO-operated name server located at one point in the Internet that responds to DNS queries sent to that RSO’s IPv4 or IPv6 address.”? Page 12: Root Zone first bullet: * Saying “the starting point” is likely to be confusing. Perhaps “The collection of TLDs and their name servers and the addresses of those name servers”? Root Zone third bullet: * Perhaps “Compiled, DNSSEC-signed, and made available by the Root Zone Maintainer to all root server operators.”? Root Zone last bullet: * Perhaps “The information the root name servers provide in response to DNS queries to root server IP addresses”? Perhaps add a bullet saying something like “How the root zone is managed discussed in RZERC”? Root Server System second bullet: * Wrong column? It’s the root zone that’s served, not the root server system. Perhaps "Currently implemented via 13 IPv4 and 13 IPv6 addresses, from over 1800 instances.” Root Server System third bullet: * Perhaps: "Purely technical role to publish what is created, signed, and made available by the RZM.”? Root Server System fourth bullet: * This gets philosophical. I could be wrong, but I’m unsure there is consensus on that particular statement, e.g., do all 13 RSOs agree that the RSS as a whole is their responsibility and not that their RSO is their responsibility? Perhaps “A voluntary collaboration of the 13 RSOs”? Perhaps add a bullet saying something like “How the root server system is managed will be discussed in the RSS-GS”? Page 15: * I thought Verisign got rid of the capital ’S’? * ‘G’ should probably be “US DOD Defense Information Systems Agency"? Page 36: * As I understood it, one of the prime drivers for RSS governance is to improve accountability. There is no mention of this. Regards, -drc
https://docs.google.com/presentation/d/1arBlU1OKHvx2ju-Sgw5lA-rxpmiSsURtnLL4...
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.
Hi, A few comments 1. On Page 5 The slide states that "Original Problem" "IP addresses often change". Then the footnote states that "It used to be a one-to-one mapping of IP address to machine on Internet. Now things are much more complicated." I understand that if it is explained properly there is no conflict however there is a conflict in what is written down as the slide states that Ip addresses often changes and the footnote states that originally it was one to one mapping. 2. It might not be so important but it would be good to have a slide on IDN or change the examples on slides 6 and 7 to reflect IDNs or not just 3 letters TLDs. 3. to new people, slide 16 might be confusing if not properly explained cos for example in Africa you have 80 and 75.. can it just be region by region to make it better to understand by just looking at it. Cheers AK On Wed, Jan 15, 2025 at 1:13 AM David Conrad via rssac-caucus < rssac-caucus@icann.org> wrote:
Hi,
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?
A few suggestions:
Page 5:
Many (most?) non-technical folks will: * probably associate the word “object” with a physical thing. Why not “The system that translates a name into different types of information associated with that name”? * hear the words "distributed, loosely coherent, scalable, dynamic database” as the equivalent of what technical folks would describe as "terminal noise.” Is that sentence useful?
Page 8: * Non-technical folks may interpret “TLD servers” as something other than the name servers for the TLDs, perhaps "Root servers only provide information about themselves and top-level-domain (TLD) nameservers”? * Non-technical folks may interpret “records” to be something other than attributes associated with a name, perhaps “TLD information returned by root name servers have TTLs of one or two days”?
Page 9: * I’m a bit unclear as to why DOH/DOT are mentioned here, since they’re unrelated to the root servers.
Page 11: First bullet: * Non-technical folks may interpret “all the information necessary to contact the TLDs” to mean telephone numbers, email addresses, etc. Perhaps "It has no parent and contains only the names and addresses of the TLDs name servers”? (I know it’s not strictly accurate, but the details probably aren’t important to the How It Works crowd). Alternatively, “It has no parent and contains only the information necessary to create secure delegation of authority to the TLDs” (might be too technical)?
Second bullet: * Perhaps use “publish” instead of serve?
Third bullet: * Perhaps "An organization responsible for running a name server on one of the IPv4/IPv6 pairs of addresses identified as a root name server in the root zone”?
Fourth bullet: * Perhaps “An RSO-operated name server located at one point in the Internet that responds to DNS queries sent to that RSO’s IPv4 or IPv6 address.”?
Page 12: Root Zone first bullet: * Saying “the starting point” is likely to be confusing. Perhaps “The collection of TLDs and their name servers and the addresses of those name servers”?
Root Zone third bullet: * Perhaps “Compiled, DNSSEC-signed, and made available by the Root Zone Maintainer to all root server operators.”?
Root Zone last bullet: * Perhaps “The information the root name servers provide in response to DNS queries to root server IP addresses”?
Perhaps add a bullet saying something like “How the root zone is managed discussed in RZERC”?
Root Server System second bullet: * Wrong column? It’s the root zone that’s served, not the root server system. Perhaps "Currently implemented via 13 IPv4 and 13 IPv6 addresses, from over 1800 instances.”
Root Server System third bullet: * Perhaps: "Purely technical role to publish what is created, signed, and made available by the RZM.”?
Root Server System fourth bullet: * This gets philosophical. I could be wrong, but I’m unsure there is consensus on that particular statement, e.g., do all 13 RSOs agree that the RSS as a whole is their responsibility and not that their RSO is their responsibility? Perhaps “A voluntary collaboration of the 13 RSOs”?
Perhaps add a bullet saying something like “How the root server system is managed will be discussed in the RSS-GS”?
Page 15: * I thought Verisign got rid of the capital ’S’? * ‘G’ should probably be “US DOD Defense Information Systems Agency"?
Page 36: * As I understood it, one of the prime drivers for RSS governance is to improve accountability. There is no mention of this.
Regards, -drc
https://docs.google.com/presentation/d/1arBlU1OKHvx2ju-Sgw5lA-rxpmiSsURtnLL4...
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.
-- Website <http://www.unilorin.edu.ng>, Weekly Bulletin <http://www.unilorin.edu.ng/index.php/bulletin> UGPortal <http://uilugportal.unilorin.edu.ng/> PGPortal <https://uilpgportal.unilorin.edu.ng/> HelpDesk <http://www.unilorin.edu.ng/index.php/more-resources/e-notices/6845-how-to-re...>
Hi, Slide 11 (Useful definition), the term "root server anycast instance" was defined without defining the more general concept of a "root server instance", Regards, Dessalegn On Wed, Jan 15, 2025 at 11:28 AM Abdulkarim Oloyede via rssac-caucus < rssac-caucus@icann.org> wrote:
Hi, A few comments 1. On Page 5 The slide states that "Original Problem" "IP addresses often change". Then the footnote states that "It used to be a one-to-one mapping of IP address to machine on Internet. Now things are much more complicated." I understand that if it is explained properly there is no conflict however there is a conflict in what is written down as the slide states that Ip addresses often changes and the footnote states that originally it was one to one mapping.
2. It might not be so important but it would be good to have a slide on IDN or change the examples on slides 6 and 7 to reflect IDNs or not just 3 letters TLDs.
3. to new people, slide 16 might be confusing if not properly explained cos for example in Africa you have 80 and 75.. can it just be region by region to make it better to understand by just looking at it.
Cheers
AK
On Wed, Jan 15, 2025 at 1:13 AM David Conrad via rssac-caucus < rssac-caucus@icann.org> wrote:
Hi,
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?
A few suggestions:
Page 5:
Many (most?) non-technical folks will: * probably associate the word “object” with a physical thing. Why not “The system that translates a name into different types of information associated with that name”? * hear the words "distributed, loosely coherent, scalable, dynamic database” as the equivalent of what technical folks would describe as "terminal noise.” Is that sentence useful?
Page 8: * Non-technical folks may interpret “TLD servers” as something other than the name servers for the TLDs, perhaps "Root servers only provide information about themselves and top-level-domain (TLD) nameservers”? * Non-technical folks may interpret “records” to be something other than attributes associated with a name, perhaps “TLD information returned by root name servers have TTLs of one or two days”?
Page 9: * I’m a bit unclear as to why DOH/DOT are mentioned here, since they’re unrelated to the root servers.
Page 11: First bullet: * Non-technical folks may interpret “all the information necessary to contact the TLDs” to mean telephone numbers, email addresses, etc. Perhaps "It has no parent and contains only the names and addresses of the TLDs name servers”? (I know it’s not strictly accurate, but the details probably aren’t important to the How It Works crowd). Alternatively, “It has no parent and contains only the information necessary to create secure delegation of authority to the TLDs” (might be too technical)?
Second bullet: * Perhaps use “publish” instead of serve?
Third bullet: * Perhaps "An organization responsible for running a name server on one of the IPv4/IPv6 pairs of addresses identified as a root name server in the root zone”?
Fourth bullet: * Perhaps “An RSO-operated name server located at one point in the Internet that responds to DNS queries sent to that RSO’s IPv4 or IPv6 address.”?
Page 12: Root Zone first bullet: * Saying “the starting point” is likely to be confusing. Perhaps “The collection of TLDs and their name servers and the addresses of those name servers”?
Root Zone third bullet: * Perhaps “Compiled, DNSSEC-signed, and made available by the Root Zone Maintainer to all root server operators.”?
Root Zone last bullet: * Perhaps “The information the root name servers provide in response to DNS queries to root server IP addresses”?
Perhaps add a bullet saying something like “How the root zone is managed discussed in RZERC”?
Root Server System second bullet: * Wrong column? It’s the root zone that’s served, not the root server system. Perhaps "Currently implemented via 13 IPv4 and 13 IPv6 addresses, from over 1800 instances.”
Root Server System third bullet: * Perhaps: "Purely technical role to publish what is created, signed, and made available by the RZM.”?
Root Server System fourth bullet: * This gets philosophical. I could be wrong, but I’m unsure there is consensus on that particular statement, e.g., do all 13 RSOs agree that the RSS as a whole is their responsibility and not that their RSO is their responsibility? Perhaps “A voluntary collaboration of the 13 RSOs”?
Perhaps add a bullet saying something like “How the root server system is managed will be discussed in the RSS-GS”?
Page 15: * I thought Verisign got rid of the capital ’S’? * ‘G’ should probably be “US DOD Defense Information Systems Agency"?
Page 36: * As I understood it, one of the prime drivers for RSS governance is to improve accountability. There is no mention of this.
Regards, -drc
https://docs.google.com/presentation/d/1arBlU1OKHvx2ju-Sgw5lA-rxpmiSsURtnLL4...
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.
Website <http://www.unilorin.edu.ng>, Weekly Bulletin <http://www.unilorin.edu.ng/index.php/bulletin> UGPortal <http://uilugportal.unilorin.edu.ng/> PGPortal <https://uilpgportal.unilorin.edu.ng/> HelpDesk <http://www.unilorin.edu.ng/index.php/more-resources/e-notices/6845-how-to-re...>
_______________________________________________ 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.
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 instances Typically 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! W https://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.
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 contents Slide 3: IP addresses are hard to remember “because it is machine readable” or write this addition as part of the footnote/explanatory note Slide 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 Olorundare* On 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 instances Typically 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!
W
https://docs.google.com/presentation/d/1arBlU1OKHvx2ju-Sgw5lA-rxpmiSsURtnLL4...
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
Hi, Thanks for this excellent work. I am sure based on the comprehensive comments from others on this thread that the slides are likely to change drastically. Therefore my comments are only a few: * Slide 4: Another bubble (not sure these should be bubbles) is that IP addresses identify both services and people accessing those services. Otherwise the modern problems on the following slide might be confusing. * Slide 6: There are better schematics to describe this. Sorry to toot my own horn, but in my book we use the attached graphic. * Slide 9: Security, privacy, resilience-- then on the right you can describe how it's achieved but this refinement would keep the ideas simple enough to remember. Agree with others it should be moved to later in the deck. * Slides 12-13 just need a conceptual rework. It's not zone vs system, it's about who maintains which records. Build on what you've described in slide 6. You could then take each party in turn to describe how they achieve their role but slide 13 is not helpful as it is. * Slide 17-19 would seem to go into governance. Thanks, -Mallory On Thu, Jan 16, 2025 at 7:17 AM James Olorundare via rssac-caucus < rssac-caucus@icann.org> wrote:
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 contents
Slide 3: IP addresses are hard to remember “because it is machine readable” or write this addition as part of the footnote/explanatory note
Slide 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 Olorundare*
On 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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__cdn.wkumari.dev_2024-2D...> ).
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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__root-2Dservers.org_&d=Dw...>) 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 instances Typically 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!
W
https://docs.google.com/presentation/d/1arBlU1OKHvx2ju-Sgw5lA-rxpmiSsURtnLL4... <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_present...>
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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p...>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t...>). 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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_p...>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t...>). 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_p... ) and the website Terms of Service ( https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_t... ). 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.
Hi all, On 1/16/25 17:24, Mallory Knodel via rssac-caucus wrote:
* Slide 4: Another bubble (not sure these should be bubbles) is that IP addresses identify both services and people accessing those services. Otherwise the modern problems on the following slide might be confusing.
IP addresses don't identify people. (Some people use the same device.) But I get your point, so perhaps: "IP addresses identify connected devices (services, people, ...)" ... which is vague enough to transport the idea correctly (I think). Also suggest to change "hosts" to "devices" in the green bubble of that slide. These remarks triggered my email; adding some more thoughts below while I'm at it.
* Slide 6: There are better schematics to describe this. Sorry to toot my own horn, but in my book we use the attached graphic.
Both graphics describe subdomains under a registered domain (like en.wikipedia.org) as the "subdomain zone", which is not a correct use of the technical term. (Zones are things that have NS records; the name mentioned doesn't have any.)
* Slide 9: Security, privacy, resilience-- then on the right you can describe how it's achieved but this refinement would keep the ideas simple enough to remember.
+1
* Slides 12-13 just need a conceptual rework. It's not zone vs system, it's about who maintains which records. Build on what you've described in slide 6. You could then take each party in turn to describe how they achieve their role but slide 13 is not helpful as it is.
Agree about 13, but I think the "zone vs system" comparison is useful. Best, Peter -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Möckernstraße 74 10965 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525
Dear RSSAC Caucus Members, Thanks everyone who sent in comments on the How it Works slides. I took all the comments received and put them in a single Google doc. Here I responded to individual comments, sometimes saying why I implemented the comment and sometimes explaining why I didn't. https://docs.google.com/document/d/11rHehzjbJozCax9yKKGDqVCQMjSMgyU1XVaVQnzA... Here is the version I sent to the list on January 14th. I'm now calling this v1. https://docs.google.com/presentation/d/1arBlU1OKHvx2ju-Sgw5lA-rxpmiSsURtnLL4... Here is the new version of the How it Works slide deck. I'm calling this v2. https://docs.google.com/presentation/d/1asB-T9NJzgAzdmYTHYFdeNmln5a7CbS0Vlpd... Because I moved slides around you need to use the v1 slide numbers when reading the comments in the Google doc. I could not implement all of the suggestions received, but I tried to implement as many as I could. Thanks, Andrew
On 14 Jan 2025, at 21:06, Andrew McConachie <andrew.mcconachie@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?
https://docs.google.com/presentation/d/1arBlU1OKHvx2ju-Sgw5lA-rxpmiSsURtnLL4...
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
Dear RSSAC Caucus Members, The RSSAC Admin Committee decided that this version of the presentation is final for ICANN 82. We will periodically revisit this presentation before ICANN meetings and update it as necessary. Thanks, Andrew
On 30 Jan 2025, at 17:05, Andrew McConachie via rssac-caucus <rssac-caucus@icann.org> wrote:
Dear RSSAC Caucus Members,
Thanks everyone who sent in comments on the How it Works slides.
I took all the comments received and put them in a single Google doc. Here I responded to individual comments, sometimes saying why I implemented the comment and sometimes explaining why I didn't.
https://docs.google.com/document/d/11rHehzjbJozCax9yKKGDqVCQMjSMgyU1XVaVQnzA...
Here is the version I sent to the list on January 14th. I'm now calling this v1.
https://docs.google.com/presentation/d/1arBlU1OKHvx2ju-Sgw5lA-rxpmiSsURtnLL4...
Here is the new version of the How it Works slide deck. I'm calling this v2.
https://docs.google.com/presentation/d/1asB-T9NJzgAzdmYTHYFdeNmln5a7CbS0Vlpd...
Because I moved slides around you need to use the v1 slide numbers when reading the comments in the Google doc. I could not implement all of the suggestions received, but I tried to implement as many as I could.
Thanks, Andrew
On 14 Jan 2025, at 21:06, Andrew McConachie <andrew.mcconachie@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?
https://docs.google.com/presentation/d/1arBlU1OKHvx2ju-Sgw5lA-rxpmiSsURtnLL4...
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.
Thanks Andrew, for a good job well done. Sent from Gmail Mobile of Ojk On Fri, 14 Feb 2025 at 11:00, Andrew McConachie via rssac-caucus < rssac-caucus@icann.org> wrote:
Dear RSSAC Caucus Members,
The RSSAC Admin Committee decided that this version of the presentation is final for ICANN 82. We will periodically revisit this presentation before ICANN meetings and update it as necessary.
Thanks, Andrew
On 30 Jan 2025, at 17:05, Andrew McConachie via rssac-caucus < rssac-caucus@icann.org> wrote:
Dear RSSAC Caucus Members,
Thanks everyone who sent in comments on the How it Works slides.
I took all the comments received and put them in a single Google doc. Here I responded to individual comments, sometimes saying why I implemented the comment and sometimes explaining why I didn't.
https://docs.google.com/document/d/11rHehzjbJozCax9yKKGDqVCQMjSMgyU1XVaVQnzA...
Here is the version I sent to the list on January 14th. I'm now calling
this v1.
https://docs.google.com/presentation/d/1arBlU1OKHvx2ju-Sgw5lA-rxpmiSsURtnLL4...
Here is the new version of the How it Works slide deck. I'm calling this
v2.
https://docs.google.com/presentation/d/1asB-T9NJzgAzdmYTHYFdeNmln5a7CbS0Vlpd...
Because I moved slides around you need to use the v1 slide numbers when
reading the comments in the Google doc. I could not implement all of the suggestions received, but I tried to implement as many as I could.
Thanks, Andrew
On 14 Jan 2025, at 21:06, Andrew McConachie <
andrew.mcconachie@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?
https://docs.google.com/presentation/d/1arBlU1OKHvx2ju-Sgw5lA-rxpmiSsURtnLL4...
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.
participants (10)
-
Abdulkarim Oloyede -
Andrew McConachie -
David Conrad -
Dessalegn Yehuala -
James Olorundare -
Mallory Knodel -
Peter Thomassen -
Steve Crocker -
Warren Kumari -
Wessels, Duane