Subject: Re: [dnsext] an analogy

From: Brian Dickson <[email-masked]>
Date: Wed, 28 Jul 2010 13:58:01 -0300

On Wed, Jul 28, 2010 at 8:54 AM, Edward Lewis <[email-masked]> wrote:

> Analogies are terrible for arguing points or illustrating ideas (when there
> is contention) but sometimes they help when trying to define a problem.  The
> following analogy came to me in the second DNSEXR WG session and thought I
> would ask on the list for comments about the issues it raises.
>
> Pretend that I run a library, a traditional, bricks-and-mortar facility
> with real, old-fashioned books.  "In front" of my collection is a card
> catalogue.
>
> My collection is divided into genres - youth, romance, biography, sci-fi,
> animation (cartoons), reference, and so on.  Along comes a popular book, and
> I can buy just one copy, but it fits many genres - biography, romance, and a
> cartoon for example.
>
> Where do I put the book?  How do I make sure that someone who thinks of it
> as a youth book finds it?  How do I make sure that someone who thinks of it
> as a biography finds it?
>
> In this analogy, the book itself is the "first class citizen" data (records
> that can be the RDATA of a MX).  The categories are the variants of written
> scripts.
>
> What is the card catalog?  Obviously there can be pointers from the cards
> to the physical book with all of the cards being the second class citizens.
>  The open question is, what does the card catalog translate to in DNS-life
> (if this analogy holds)?  Is it part of the DNS at all, does it hint that
> maybe we have a class of "first class zones" and a class of "second class
> forwarder zones"?
>

IMNSHO, it's pretty clear that the card catalog is an authority server. As
in, for one or more zones, for which it is authoritative.
Each "section" is a separate zone, and to guarantee someone finds the book,
it needs to be put in all the appropriate section of the catalog, i.e. added
to each appropriate zone, as first class data.

NB - the card can be built so as to be multiply-labeled, as the format
includes all the places it should be filed, effectively the back-references.
Identical cards can thus be used in multiple catalogs.

And, in this analogy, a delegation would be along the lines of an entry in a
card catalog which points the user to another bricks-and-mortar facility,
and implicitly, the card catalog of that facility.

Really big libraries may in fact have duplicate card catalogs, the
maintaining of which are very close analogs to maintaining zones.
Add in electronic card catalogs to the physical paper ones, and you get a
pretty good analogy.

Note some very strong parallels in the analogy:
- The card catalog entries give pertinent details about the item, but most
specifically the "catalog number", be it LoC (library of congress) or Dewey
Decimal System. That is the "address", and the organization of the content
within the book is outside of the scope of the card catalog system. This is
very much like the protocol-dependent nature of what is on a server, found
at a given address (in response to looking up a name in DNS).
- Each entity will have a (likely non-unique) "name", one or more (i.e. N:1)
unique "catalog address(es)", and will also have a unique 1:1 identifier -
the ISBN or ISSN  (book or subscription, i.e. periodical, number).
- What is currently absent from the DNS side of things (and not just DNS) is
the unique identifier. This also impacts IP addressing and routing, and
thusly all of layer 3 and 4. Perhaps the analogous uniqueness sought is the
identity as currently validated through SSL certificates, and further
validated via DNSSEC?

The catalog is itself a set of sorted entries, where each entry is a
sequence of labels organized in a canonical fashion.
The analogy is that X.Y.Z in DNS, would already be re-organized to "Z, Y, X"
in a card catalog based on significance.
Each label sequence is fully qualified, up to the degree of uniqueness
possible for first-class data. Depending on the subject matter, the label
sequence for books can be quite long.... "Math, Pure, Algebra, Finite
Groups, Abelian, Complex".
And depending on the scope of the library, delegations to other libraries or
departments may be found for many entries:
"Please see the Geophysics Library for books on this subject."
And failure to find the desired entry may be resolved by consulting the
"master catalog", the Library of Congress catalog.
(Kind of like the root, or maybe a cache with root hints and lots of cached
data.)
(NB - the LOC catalog is... a book!)

In this analogy, BTW, catalog entries that point to books are first class
citizens, as are "delegation-style" entries. The path of delegations is
always expected to be a directed acyclic graph of reasonable depth. "QV"
entries, on the other hand, are not fundamentally bounded, and are the
analog to xNAME entries.

For important kinds of things, sticking to first-class entities (delegations
and authority data) are the only way to guarantee an authoritative answer in
bounded timeframe, whether the answer is good, NXDOMAIN, or other definitive
non-answers (SRVFAIL, NODATA, et al). Whether or not that means xNAME is
viable for the IDN issue is unclear...

Just my contribution to the meme thread.

Brian

> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis
> NeuStar                    You can leave a voice message at +1-571-434-5468
>
> Spouses, like Internet protocols, lack necessary troubleshooting tools.
> Sigh.
>
>

---

From: Hugo Salgado <[email-masked]>
Date: Sun, 01 Aug 2010 00:52:30 +0200

On 07/28/2010 06:58 PM, Brian Dickson wrote:
[...]
> - The card catalog entries give pertinent details about the item, but
> most specifically the "catalog number", be it LoC (library of congress)
> or Dewey Decimal System. That is the "address", and the organization of
> the content within the book is outside of the scope of the card catalog
> system. This is very much like the protocol-dependent nature of what is
> on a server, found at a given address (in response to looking up a name
> in DNS).
> - Each entity will have a (likely non-unique) "name", one or more (i.e.
> N:1) unique "catalog address(es)", and will also have a unique 1:1
> identifier - the ISBN or ISSN  (book or subscription, i.e. periodical,
> number).
> - What is currently absent from the DNS side of things (and not just
> DNS) is the unique identifier. This also impacts IP addressing and
> routing, and thusly all of layer 3 and 4. Perhaps the analogous
> uniqueness sought is the identity as currently validated through SSL
> certificates, and further validated via DNSSEC?
>
> The analogy is that X.Y.Z in DNS, would already be re-organized to "Z,
> Y, X" in a card catalog based on significance.
> possible for first-class data. Depending on the subject matter, the
> label sequence for books can be quite long.... "Math, Pure, Algebra,
> Finite Groups, Abelian, Complex".
> And depending on the scope of the library, delegations to other
> libraries or departments may be found for many entries:
> (Kind of like the root, or maybe a cache with root hints and lots of
> cached data.)
> In this analogy, BTW, catalog entries that point to books are first
> class citizens, as are "delegation-style" entries. The path of
> delegations is always expected to be a directed acyclic graph of
> reasonable depth. "QV" entries, on the other hand, are not fundamentally
> bounded, and are the analog to xNAME entries.

And in the libraries you have a thesaurus, where you lookup an
identifier, and get the "main entry" (the first class citizen) and
all the synonisms.

Hugo