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.