I like this approach with simple language. DW
On Jan 28, 2020, at 3:01 PM, Wes Hardaker <hardaker@isi.edu> wrote:
throwing random thoughts to the internet:
Root server identifier: the DNS name that references a root server. These are then translated into IP addresses as well. These used to be referred to as "letters", but they have not always been a "letter" and may not be in the future as well.
Root server: (all) the infrastructure maintained by a root server operator to handle root service pointed at by a given root server identifier. In the distant past, these were potentially implemented using a single physical device, or "server", but are not today.
Root server instance: A portion of a root server's infrastructure that serves root data from a particular site, which may consist of single or multiple physical devices. Anycast instance: another name for a root server instance.
and a note to go with it: These terms obsolete previous definitions and unfortunately, their usage may be incorrect in documents prior to this one.
On Tue, Jan 28, 2020 at 5:30 AM Andrew McConachie <andrew.mcconachie@icann.org> wrote: Hi Duane,
If we go with the idea that an RSI is just a name(i.e., a reference to a root server) then how should I interpret the following sentence from the Metrics doc?
"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.”
How can an RSI be reachable if it is only a reference to something physical? I would expect the physical thing to be that which is reachable, the entry point.
Reading through the Metrics doc 'root server' and 'root server identity’ are used somewhat synonymously throughout. It makes me wonder if we even need two separate terms. Both terms are fairly conceptual in nature, with much of the physicality we could ascribe to either already covered by the term ‘instance’. Maybe we just declare ‘root server’ and ‘root server identity' as synonyms?
Here is another sentence from page 8: "Whereas those are mostly tabulating various aspects of traffic to individual root servers, these assess the performance, availability, and quality of service that each root server and the overall system provides.”
In this sentence traffic is sent to ‘root servers’, not RSI’s. So they take the physical form in this sentence unlike in the first example, which also gives ‘root servers’ the role of entry point to the RSS. For either example sentence I think we could swap the terms with each other and they would both continue to make sense.
Paul is right in his response that the Caucus did agree to develop RSSAC026v2 based on the definitions coming out of the Metrics work. And I definitely don’t want to revisit the Metrics work. My only concern is that we come up with definitions for RSSAC026v2 that match the usage in the Metrics doc, and ideally those definitions are easily understandable to people not on this list.
Thanks, Andrew
On Jan 27, 2020, at 22:12, Wessels, Duane <dwessels@verisign.com> wrote:
Hi Andrew,
I agree with Terry's interpretation. "root server" encompasses hardware, software, and other operational components. Its identity is just its name -- how we refer to it.
I also agree that the current RSSAC026v2 definitions don't match this interpretation very well. IMO most of what is currently under "root server" would fit better under "root server identity" and we probably need a new definition for root server.
Thinking about the Introduction figure in the v2, I wonder if it would be helpful to draw a "root server" box around all of the boxes for identity, address, and instances?
DW
On Jan 27, 2020, at 5:15 AM, Terry Manderson <terry@terrym.net> wrote:
Hi Andrew,
My interpretation is that a “root server identity” is the naming components for a “root server” in both the root zone and the hints file, .....and that a “root server” is the operational part that responds with appropriate and well formed DNS answers to DNS queries from all parts of the internet directed at the root server identity.
It seems very nuanced and I’d love to be able to simplify the way this is communicated.
Does that help?
Cheers, Terry -- Mobile device, don't expect grammar.
On 27 Jan 2020, at 8:42 pm, 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.
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.
_______________________________________________ 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.
-- Wes Hardaker USC/ISI