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

Wed Jan 29 00:25:11 UTC 2020

> On Jan 28, 2020, at 5:30 AM, Andrew McConachie <andrew.mcconachie at 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 at 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 at 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 at 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 at 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-LDlb58/edit?usp=sharing [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 at 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_policy&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KNEpS67O2txk54bIz-1lXP0tI5Rmtg88Ogwh6PVSGXJyTMuY0E2SHr70jrG3fGLJ&m=AbMEnyPrB2A0Sjuu5gFDD8iIwBtzdnKsXLnUFAtDexI&s=FF0WFUvi4JsohMKSZN8km9_VKmxlG5hO5e7SyjIfQMc&e= ) and the website Terms of Service (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=KNEpS67O2txk54bIz-1lXP0tI5Rmtg88Ogwh6PVSGXJyTMuY0E2SHr70jrG3fGLJ&m=AbMEnyPrB2A0Sjuu5gFDD8iIwBtzdnKsXLnUFAtDexI&s=Vms8zygCBV-2_TYCDAUhWN9kYemmYK6C-Rv2scp5RI4&e= ). 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 at 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 at 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.
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4695 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20200129/05bcd014/smime.p7s>