[RSSAC Caucus] [Ext] FOR REVIEW: RSSAC026v2: RSSAC Lexicon

[Matt Larson]

> On Jan 31, 2020, at 11:18 AM, Paul Hoffman <paul.hoffman at icann.org <mailto:paul.hoffman at icann.org>> wrote:
> 
>>> On Jan 30, 2020, at 9:25 PM, Paul Hoffman <paul.hoffman at icann.org <mailto:paul.hoffman at icann.org>> wrote:
>>> 
>>> On Jan 30, 2020, at 5:50 PM, Paul Vixie <paul at redbarn.org <mailto:paul at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20200131/748de931/attachment.html>