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

Tue Jan 28 23:01:58 UTC 2020

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

-- 
Wes Hardaker
USC/ISI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/rssac-caucus/attachments/20200128/0ec5deec/attachment.html>