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.

Andrew brings up some good points here. It is clear that the metrics document uses some wrong terms in some places, although probably in ways that can be understood by someone who understand the new terminology. However, 026v2 is not finished, so we are not even sure which terms to use where in the metrics document. --Paul Hoffman

Hi Warren, “Letters” actually create a lot of confusion, especially when talking and thinking about measurements. This vernacular also has created a pain in geo-political arenas as it isn’t clear as to what that means precisely. (I am still living through this) So folks not of a tech background and suitably imbued with historical technical knowledge then apply their their own interpretation. It is stunningly hard to argue against such interpretations without clear definitions in existence. Of course translation to other languages is a curve ball in its own right. So the problem is that “the spade” is only a spade if you have seen one before. Cheers, Terry -- Mobile device, don't expect grammar.

On 29 Jan 2020, at 2:02 am, Warren Kumari <warren@kumari.net> wrote:

I realize that this is not going to be popular / likely to succeed, but we seem to have created a lot of confusion for ourselves by desperately trying to avoid calling them "letters"; the term "letter" is the colloquial term, and I think that we all largely instinctively understand what it means - I know I hear root server operators, dns people, etc continuing to use the term without confusion -- I still believe we would be well suited to just "call a spade a spade", and not overcomplicate things....

W

...

On Tue, Jan 28, 2020 at 10:52 AM Paul Hoffman <paul.hoffman@icann.org> wrote:

Andrew brings up some good points here. It is clear that the metrics document uses some wrong terms in some places, although probably in ways that can be understood by someone who understand the new terminology. However, 026v2 is not finished, so we are not even sure which terms to use where in the metrics document.

--Paul Hoffman_______________________________________________ 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.

-- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ 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.

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

"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."

there have always been more than one routing instance of a server identity in some site.

IMHO, I didn't say otherwise in my text. An instance is welcome to have more than one route per site. Or maybe you're arguing that two "instances" can occur at a site. Note that my text also didn't say "unique at a site" either. (but my text was a starting proposal to think about, not such much final wording choices) -- Wes Hardaker USC/ISI

We could, as the layering goes on, define “anycast site” as an entry into the routing system which then is apropos actual usage and less about physical interpretations or indeed the number of instances that happen to be at that anycast site. Just a thought.

That works for me too. I hesitate to create more terms just for the sake of it. When speaking to a large number of people that really don't grasp the technology well, less terms is often more useful that more terms. Conversations at ICANN meetings tend to prove this. But maybe the right attitude is to drop complex terms in simple conversations.

I like this a lot. Kudos for the words Wes! Cheers, Terry -- Mobile device, don't expect grammar.

On 29 Jan 2020, at 10:14 am, Wessels, Duane via rssac-caucus <rssac-caucus@icann.org> wrote:

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

_______________________________________________ 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' formulation seem close to me. I disagree with the proposal that this document should define "anycast" and "anycast routing instance" or "anycast site": that won't help almost any reader of the document. Those things are important to the operators, but there is enough variety of operations that nailing those down by definitions would not be helpful. However, there is some circularity and repetition that might get in the way for use of the terms. The following is based on Wes' proposal, along with Terry's idea. It has a bit of editing to match the current formatting, to simplify, and to tie the definitions together a bit closer. It is presented in the order it could appear in the document. ===== root server operator ## identical to current document A root server operator is an organization responsible for managing the root service on IP addresses specified in the root zone and the root hints file. This term is often abbreviated as “RSO”. root server identifier A root server identifier is the DNS name for a root server operator that appears in the root zone and root hints file. root server A root server is all of the infrastructure that is maintained by a root server operator to handle the root service at the IP addresses associated with the root server identifier in the root zone and the root hints file. root server instance A root server instance is the portion of a root server operator's infrastructure that serves root data at one of the IP addresses associated with a root server identifier. instance (anycast instance) ## remove current text altogether root server identity ## remove current text altogether ===== Thoughts? --Paul Hoffman

On 1/29/20 8:33 PM, Paul Vixie wrote:

we have dispensed with 'site' and 'location' as relationships which would define a 'portion of' as a 'root server instance', and that's good (says me).

Personally, I'm not ready to give up on location/site as part of the RSSAC definition for instance.  When we're at an RSSAC meeting discussing instances, location is the primary way we identify them. I really liked the plain language Wes used in his recent definitions and i'm concerned your more technically accurate definition will confuse much of our RSSAC audience.

"A root server instance is the portion of a root server operator's infrastructure [dedicated to serving] root data at one [or more] of the IP addresses associated with a root server identifier [and having connectivity disjoint from all other instances of the same server]."

What differentiates the connectivity between C-root's New York and Chicago instances?  I assume (perhaps wrongly) that they are both connected to Cogent's network and fall under a common BGP routing policy.  To me, you need to use location to best describe that difference. -Karl

On Thursday, 30 January 2020 13:56:04 UTC Karl Reuss wrote:

On 1/29/20 8:33 PM, Paul Vixie wrote:

...

we have dispensed with 'site' and 'location' as relationships which would define a 'portion of' as a 'root server instance', and that's good (says me). Personally, I'm not ready to give up on location/site as part of the RSSAC definition for instance. When we're at an RSSAC meeting discussing instances, location is the primary way we identify them. I really liked the plain language Wes used in his recent definitions and i'm concerned your more technically accurate definition will confuse much of our RSSAC audience.

as before, there have been, are now, and will be cases where two instances of the same identifier are in adjacent racks in some data center that has more than one internet exchange present. location will be the same. SFO1 and SFO2 might be in different parts of the san francisco airport's region, or they might be in the same rack but with disjoint upstream connectivity. this is a topologic location difference without a geographic location difference. it is the topologic location that matters.

...

"A root server instance is the portion of a root server operator's infrastructure [dedicated to serving] root data at one [or more] of the IP addresses associated with a root server identifier [and having connectivity disjoint from all other instances of the same server]."

What differentiates the connectivity between C-root's New York and Chicago instances? I assume (perhaps wrongly) that they are both connected to Cogent's network and fall under a common BGP routing policy. To me, you need to use location to best describe that difference.

ingress and egress paths are very different for new york vs. chicago, if queries are coming from nearby one or the other. only in the case where the query source is quite distant from both, will there be ingress or egress path similarity among query sources. but since our network is global, anything far enough away from new york and chicago to yield path blending, will likely be closer to some other instance. that's why topological location is important. -- Paul

Omnibus reply...

On Jan 29, 2020, at 7:47 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:

root server identifier A root server identifier is the DNS name for a root server operator that appears in the root zone and root hints file.

Strictly speaking, a root server identifier is not a name "for" an RSO; it is a name associated with an RSO. So how about: root server identifier A root server identifier is the DNS name associated with a root server operator that appears in the root zone and root hints file.

On Jan 30, 2020, at 9:25 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:

On Jan 30, 2020, at 5:50 PM, Paul Vixie <paul@redbarn.org> wrote:

...

On Thursday, 30 January 2020 13:56:04 UTC Karl Reuss wrote:

...

On 1/29/20 8:33 PM, Paul Vixie wrote:

...

we have dispensed with 'site' and 'location' as relationships which would define a 'portion of' as a 'root server instance', and that's good (says me). Personally, I'm not ready to give up on location/site as part of the RSSAC definition for instance. When we're at an RSSAC meeting discussing instances, location is the primary way we identify them. I really liked the plain language Wes used in his recent definitions and i'm concerned your more technically accurate definition will confuse much of our RSSAC audience.

If folks really like "site", we could go back to something close to Wes' original wording ("...that serves root data from a particular site...") with: A root server instance is the portion of a root server operator's infrastructure that serves root data at one site using one of the IP addresses associated with a root server identifier.

I am sympathetic to the need to include a notion of topological location in the definition of instance: I don't think there's a way around it. How about we simply (he writes, hopefully) qualify "site" as topological location: A root server instance is the portion of a root server operator's infrastructure that serves root data at one site (i.e., topological location [on the Internet]) using one of the IP addresses associated with a root server identifier. (The bracketed text is redundant but adds clarity.) I know "i.e." is a bit clunky (Paul Hoffman consistently tries to remove it when editing my writing), but I think it serves a good purpose here. Matt

On Jan 31, 2020, at 11:18 AM, Paul Hoffman <paul.hoffman@icann.org <mailto:paul.hoffman@icann.org>> wrote:

...

...

On Jan 30, 2020, at 9:25 PM, Paul Hoffman <paul.hoffman@icann.org <mailto:paul.hoffman@icann.org>> wrote:

On Jan 30, 2020, at 5:50 PM, Paul Vixie <paul@redbarn.org <mailto:paul@redbarn.org>> wrote:

...

On Thursday, 30 January 2020 13:56:04 UTC Karl Reuss wrote:

...

On 1/29/20 8:33 PM, Paul Vixie wrote:

...

we have dispensed with 'site' and 'location' as relationships which would define a 'portion of' as a 'root server instance', and that's good (says me). Personally, I'm not ready to give up on location/site as part of the RSSAC definition for instance. When we're at an RSSAC meeting discussing instances, location is the primary way we identify them. I really liked the plain language Wes used in his recent definitions and i'm concerned your more technically accurate definition will confuse much of our RSSAC audience.

If folks really like "site", we could go back to something close to Wes' original wording ("...that serves root data from a particular site...") with: A root server instance is the portion of a root server operator's infrastructure that serves root data at one site using one of the IP addresses associated with a root server identifier.

I am sympathetic to the need to include a notion of topological location in the definition of instance: I don't think there's a way around it. How about we simply (he writes, hopefully) qualify "site" as topological location:

A root server instance is the portion of a root server operator's infrastructure that serves root data at one site (i.e., topological location [on the Internet]) using one of the IP addresses associated with a root server identifier.

(The bracketed text is redundant but adds clarity.)

Another problem with including "topological location" is that it is not accurate for some of the RSOs who use load balancers. That is, some RSOs treat all hosts behind a load balancer as different sites with different NSIDs, while other RSOs treat them all the same (emitting the same NSID).

Yes, this is two layers of topology, but they are real for some RSOs today. We can maybe ignore that by including the "topological location" text above, but given that we know today that it is not fully accurate, I think we are better off not cementing it in a definition.

First, I don't think different NSID values imply different "sites". E.g., it would be reasonable to name each server in a "site" differently, such as sfo-ns1, sfo-ns2, etc. Second, I submit that multiple servers behind a load balancer or a router with ECMP are indeed in the same topological location and it's unnecessarily splitting hairs to suggest otherwise. In other words, I think your suggested inaccuracy is not really inaccurate. Matt

"I am sympathetic to the need to include a notion of topological location in the definition of instance: I don't think there's a way around it. How about we simply (he writes, hopefully) qualify "site" as topological location: A root server instance is the portion of a root server operator's infrastructure that serves root data at one site (i.e., topological location [on the Internet]) using one of the IP addresses associated with a root server identifier. (The bracketed text is redundant but adds clarity.)" +1. ⁣Get BlueMail for Android ​ On 1 Feb 2020, 03:21, at 03:21, Matt Larson <matt@kahlerlarson.org> wrote:

Omnibus reply...

...

On Jan 29, 2020, at 7:47 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:

root server identifier A root server identifier is the DNS name for a root server operator that appears in the root zone and root hints file.

Strictly speaking, a root server identifier is not a name "for" an RSO; it is a name associated with an RSO. So how about:

root server identifier A root server identifier is the DNS name associated with a root server operator that appears in the root zone and root hints file.

...

On Jan 30, 2020, at 9:25 PM, Paul Hoffman <paul.hoffman@icann.org> wrote:

On Jan 30, 2020, at 5:50 PM, Paul Vixie <paul@redbarn.org> wrote:

...

On Thursday, 30 January 2020 13:56:04 UTC Karl Reuss wrote:

...

On 1/29/20 8:33 PM, Paul Vixie wrote:

...

we have dispensed with 'site' and 'location' as relationships

which would

...

...

...

define a 'portion of' as a 'root server instance', and that's good (says me). Personally, I'm not ready to give up on location/site as part of the RSSAC definition for instance. When we're at an RSSAC meeting discussing instances, location is the primary way we identify them. I really liked the plain language Wes used in his recent definitions and i'm concerned your more technically accurate definition will confuse much of our RSSAC audience.

If folks really like "site", we could go back to something close to Wes' original wording ("...that serves root data from a particular site...") with: A root server instance is the portion of a root server operator's infrastructure that serves root data at one site using one of the IP addresses associated with a root server identifier.

I am sympathetic to the need to include a notion of topological location in the definition of instance: I don't think there's a way around it. How about we simply (he writes, hopefully) qualify "site" as topological location:

A root server instance is the portion of a root server operator's infrastructure that serves root data at one site (i.e., topological location [on the Internet]) using one of the IP addresses associated with a root server identifier.

(The bracketed text is redundant but adds clarity.)

I know "i.e." is a bit clunky (Paul Hoffman consistently tries to remove it when editing my writing), but I think it serves a good purpose here.

Matt

_______________________________________________ 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.

On 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.”

It's fine with me to drop "identities" here.

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?

I could probably live with that as well. During the writing of the metrics doc, before we settled on using Root Server Identity, we also (breifly?) considered just using "Root Server" for the section 5 metrics.

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.

Yes. When we agreed to use RSI and I went through to document changing "RSO" to "RSI" in various places, I struggled with where in the document to start using the RSI term. Right now RSI is introduced and first used in the first part of section 4 (other than the table of contents and the part of the introduction that lists all the sections). Your quote above from page 8 is before section 4, so I did not put RSI there. The other sentence you quoted above is from section 4.9, after RSI had been introduced. But as I said, let's change these so that they make sense and are consistent. DW

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.

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.