FOR REVIEW: RSSAC026v2: RSSAC Lexicon
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... 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
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<mailto: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]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_documen...> 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<mailto: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.
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.
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.
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.
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
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
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.
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
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
i don't. this part is wrong, and cannot be made right in simple language. "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. i think we need Brian's language not wes's. vixie Get BlueMail for Android On 29 Jan 2020, 13:14, at 13:14, "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.
"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
Even though it is a starting point, it provides better clarity than what I’ve seen before. 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. Cheers, Terry -- Mobile device, don't expect grammar.
On 29 Jan 2020, at 10:58 am, Wes Hardaker <hardaker@isi.edu> wrote:
"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 _______________________________________________ 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.
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.
On Tue, Jan 28, 2020 at 8:29 PM Wes Hardaker <hardaker@isi.edu> wrote:
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.
(Copied and tweaked from another thread) Here's a brief attempt at this: Anycast is the routing technique of advertising the reachability of a
prefix from more than one router, typically (but not exclusively) as a global BGP announcement.
An *anycast routing instance* is a single such routing announcement. Root Server Instance (aka *anycast instance of a root server identity)* is
the server or set of servers reachable via a single* anycast routing instance* of the corresponding identity's IPv4 and/or IPv6 prefix.
It leaves unspecified any of the (IMHO unimportant details) of what the servers actually are (physical/virtual, dedicated/shared), and leaves the "network location" as an abstracted "anycast routing instance", for similar reasons. It also allows for flexibility in whether the servers are single-stack or dual-stack for IPv4/IPv6 announcements/services. Thoughts? Brian
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.
On 1/28/20 6:01 PM, Wes Hardaker 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.
I strongly support this this simple language approach! -Karl
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 Thursday, 30 January 2020 00:47:11 UTC Paul Hoffman wrote:
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.
i see what you want and i understand why you want it. however, i do not think this goal is achievable. i'll explain in detail, below.
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.
thank you for this draft, it's an excellent next step toward publication. for brevity, i will omit most of the text which i think is perfect.
=====
root server operator ...
root server identifier ...
root server ...
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 ... root server identity ## remove ...
=====
in the elided (...) text, there's an implication that an operator with two identifiers (like verisign with A and J) is the same as an operator with two addresses (like IPv4 and IPv6). this probably deserves to be clarified, because an instance can serve multiple addresses in the second case but not in the first case. but i will not focus on that element in this review.
Thoughts?
i harkened to brian's observation that the foundation of meaning for the term 'root server instance' was its reachability. your definition accurately removes 'site' and 'location' which are not accurate discriminators, but leaves us with no discriminator at all, because there is no discriminant for the word 'portion'. it's not just any portion, it's a very particular portion. for example at cogentco, C has two servers per instance, using ECMP load balancing, and these are called 'a' and 'b'. one allowable 'portion of a root server operator's infrastructure that serves root data at one of the IP addresses associated with' C root would be all of the 'a' boxes worldwide. this would be crazy, since the 'a' boxes are not related to each other other than by their similarities of purpose and of configuration. 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). what remaining relationship do the constituents of such a 'portion' actually have, that makes that 'portion of' into an 'instance'? in brian's draft, the relationship was based on reach. that is, on shared connectivity which is disjoint from all constituents of all _other_ instances of the same root server. if we don't want to talk about routing or mention the word "anycast" i'll be fine with that. in the past, some f-root instances were private, available within some autonomous system but in no way globally reachable. those were 'instances' and they do fit some technical definitions of 'anycast' but not others (because an IGP like OSPF is different from an EGP such as BGP.) so, 'anycast' is tarnished with confusion, and i'm happy to see it go. however, we have to have a discriminant for 'portion of'. my proposal is: "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]." -- Paul
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 Thu, Jan 30, 2020 at 5:56 AM Karl Reuss <reuss@umd.edu> 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.
I don't think the instance description or methodology needs to be uniform. After all, an instance is only ever an instance of a *single* root-server's anycast footprint. E.g. you can say "instance X of b.root-servers.net", but not "instances at location X", since those are apples to oranges comparisons. The naming scheme used by any particular root server operator's instances should be left up the the operator. The only real requirement is that for any particular operator, their instances should be named uniquely, but I think everyone will agree that is only sensible. Insisting on a uniform naming is only going to cause problems, and IMHO doing so (uniform naming) accomplishes nothing particularly useful. Brian
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
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. The reason I didn't do that in the text I proposed is because we would probably have to define "site" because...
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.
Now that RSOs are partnering with cloud providers to greatly increase the number of instances, it is quite possible that an RSO would have two instances in the same datacenter, but with very different routing being used for each.
this is a topologic location difference without a geographic location difference. it is the topologic location that matters.
Is it important to the reader of this document? Sure, it is important to someone debugging queries getting unexpected answers, but that is not the target reader here. I remain unconvinced that we need to tie the general definition to a topologic location. For some discussions, we need to, but in general all that matters is that a request got to an instance based on an IP address associated with the RSO. --Paul Hoffman
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 6:21 AM, 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.
That works for me, and removes the semicolon as well.
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.)
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. --Paul Hoffman
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
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).
One of the reasons I put "site" in my wording was the target audience. The difficulty comes in trying to have conversations, especially at venues like ICANN, where the people in the conversation don't need to have intricate details about how things work, but do care deeply about topology and political borders. IE, our target audience after seeing a list of terms that doesn't talk about instances being "in places" will still be left confused by how to rectify that in their heads. There is nothing wrong with two instances being in the same rack, I agree completely. Certainly we don't want wording to say "and must be unique at that site", but I don't think we were headed that way. -- Wes Hardaker USC/ISI
"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 Wed, Jan 29, 2020 at 4:47 PM Paul Hoffman <paul.hoffman@icann.org> wrote:
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.
I think the question isn't whether "anycast" is necessary, it is rather whether including "anycast" (definition and reference) improves understanding, including to those less familiar or less technical. Having a fairly high-level/generic description of anycast, along with a few examples, might suffice, rather than having to nail down definitions. Examples could include the following: - External BGP announcements from a stand-alone instance (not hosted on anyone else's network infrastructure) - Internal BGP announcements, when instances are hosted on someone else's network infrastructure (including the possibility of a single external BGP announcement effectively covering multiple instances learned via internal BGP) - Non-BGP announcements, when instances are hosted on someone else's network infrastructure. Those could include OSPF or ISIS. The high-level description of an anycast instance might need to indicate that what distinguishes a single instance from something that contains multiple instances, is whether all the hosts that can be reached on the IP address of the RSI, are behind a single router or a small number of routers (e.g. in an ECMP scheme). It may be sufficient to explain that from a particular vantage point, it is expected that all queries in a small time window, should only reach a single anycast instance, although they may reach a variety of servers within that instance. Two distinct vantage points will either hit the same instance, or two different instances. It may also be helpful in describing the nature of anycast instances creating what amounts to a "watershed" as far as vantage points are concerned. I.e. what the definitions should try to do, IMHO, is allow a person unfamiliar with anycast to understand why they see what they see when looking at root server identities, regardless of whether the word "anycast" is used. Brian
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.
Wessels, Duane via rssac-caucus writes:
When we agreed to use RSI and I went through to document changing "RSO" to "RSI" in various places, ...
I'm onboard with the direction Wes has taken things but an immediately obvious problem is that it defined two terms that both readily form RSI as a initialism, and we all know that we'll never be able to stop ourselves from initialisms. One way to address this would be to establish early on that a Root Server Identity is RSID and an instance can be just RSI. Or maybe change Identity to Name or Tag or something. I'm not that particular about it, just hoping it gets resolved unambiguously before Duane does another search and replace.
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.
On Jan 27, 2020, at 2:42 AM, Andrew McConachie <andrew.mcconachie@icann.org> wrote:
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?
We already agreed that we would update the definition from the v1 document. The v1 definition is: A root server is the name of an entry point (instance) to the root server system cloud. Within the DNS technical community, a root server is a particular anycast instance, i.e. an authoritative name server that answers queries for the contents of the root zone. In the v2 document, we have created a new term, "root server identity": Root server identity refers to the DNS name assigned to a root server. This term is often abbreviated as “RSI”. From a technical perspective, root server identities are the entry points for resolvers to the root server system. This is because most (but not all) resolvers use configuration that looks like a set of RRsets based on the IANA root hints file. For example, from the current root hints file: . 3600000 NS H.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 3600000 A 198.97.190.53 H.ROOT-SERVERS.NET. 3600000 AAAA 2001:500:1::53 Note that there is no "official" format for IANA's root hints file: RFC 1034 is silent on that. However, it is easy to imagine that most resolver software that uses that file expects something like a master file with "." as the origin. (Others might just use a list of IP addresses, for example.) One way to think of a "root server" is the server a resolver would get if it asked its cache for the authoritative server for "."; the resolver gets that address by priming (RFC 8109) from its configuration. If folks like that derived definition, then we could revise the definition in the doc to be: A root server is a DNS server that is authoritative for the root zone, based on information in the root zone itself. Although a “server” traditionally means a single computer, a root server can be a collection of instances as defined above. This definition is technically accurate but not terribly helpful when used in real life. Thus, it should probably not be used in the metrics document by itself, and all text in that document should refer to RSOs, RSIs, and instances. --Paul Hoffman
participants (13)
-
Andrew McConachie -
Brian Dickson -
Danielle Rutherford -
Dave Lawrence -
Fred Baker -
Karl Reuss -
Matt Larson -
Paul Hoffman -
Paul Vixie -
Terry Manderson -
Warren Kumari -
Wes Hardaker -
Wessels, Duane