I'm happy to be told I'm wrong, but the following reflects my understanding. Right now, we have twelve root server operators, each operating one or two identities. The identities have historically been letters - Verisign operates A and J, ISC operates F, and so on. When we say that a company-or-whatever operates an identity, we mean that it operates a constellation of root servers, each of which serves the IANA-defined root dataset to those that send it queries. An identity is a set of root servers (individual machines running application processes, whether physical or virtual machines) operated by a Root Server Operator. To the extent that we depart from that notion, I submit that we are making a simple thing complex and tripping over our collective tongues.
On Jan 27, 2020, at 2:42 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
Dear All,
I’m having a hard time understanding the difference between a ‘root server’ and a ‘root server identity’. In the draft RSSAC026v2 it says a ‘root server’ is an entry point to the RSS, and a ‘root server identity' is the DNS name of a 'root server’.
Yet on page 13 of the Draft RSS Metrics doc it says: "The requirement of k=8 for reliable operation (of the current system) reflects the number of root server identities reachable by the vantage points, which is different than the number of anycast instances that may be operating.”
Then on page 14 it says: "Furthermore, note that a single [root server] identity refers to the IPv4 and IPv6 addresses for the corresponding service."
The definitions in RSSAC026v2 do not match the usage in the draft RSS Metrics doc.
One way to resolve this would be to deprecate the usage of ‘root server’ and completely replace it with ‘root server identity’. However, this would require edits to both documents since the draft RSS Metrics doc also uses ‘root servers’ in a few places.
Ideas?
—Andrew
On Jan 24, 2020, at 01:14, Danielle Rutherford <danielle.rutherford@icann.org> wrote:
Dear RSSAC Caucus,
Please find for your review the draft version 2 of the RSSAC Lexicon: https://docs.google.com/document/d/14Un1lCkek4aAyCi9a_oBcoRP02kJ72NtX1ic-LDl... [docs.google.com]
Please review the document and provide any final comments by close-of-business everywhere Thursday, 30 January 2020.
Note: there is still one unresolved comment in the document regarding the use of the word “server” or “location” in the definition for the term “instance (anycast instance)” at the top of page 5. Karl Reuss sent out an email to the Caucus regarding this definition earlier today, 23 January. Can the Caucus please discuss this comment on the list and reach an agreement by 30 January?
Thanks, Danielle _______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://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.
_______________________________________________ rssac-caucus mailing list rssac-caucus@icann.org https://mm.icann.org/mailman/listinfo/rssac-caucus
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.