Search layering and the DNS -- The IETF52 BOF

John C Klensin <> Sun, 02 December 2001 19:14 UTC

Return-Path: <>
Received: from by (PMDF V6.0-025 #44856) id <> (original mail from; Sun, 02 Dec 2001 14:14:15 -0500 (EST)
Received: from by (PMDF V6.0-025 #44856) id <> for (ORCPT; Sun, 02 Dec 2001 14:14:15 -0500 (EST)
Received: from by (PMDF V6.0-025 #44856) id <> for (ORCPT; Sun, 02 Dec 2001 14:14:14 -0500 (EST)
Received: from ([]) by (PMDF V6.0-025 #44856) with ESMTP id <> for; Sun, 02 Dec 2001 14:14:14 -0500 (EST)
Received: from [] (helo=P2) by with esmtp (Exim 3.22 #1) id 16Ac0S-0009Bu-00 for; Sun, 02 Dec 2001 19:10:28 +0000
Date: Sun, 02 Dec 2001 14:10:27 -0500
From: John C Klensin <>
Subject: Search layering and the DNS -- The IETF52 BOF
Message-id: <204458067.1007302227@P2>
MIME-version: 1.0
X-Mailer: Mulberry/2.1.1 (Win32)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Content-disposition: inline
List-Owner: <>
List-Post: <>
List-Subscribe: <>, <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Help: <>, <>
List-Id: <>


I've deliverately avoiding posting a note to this list before
draft-klensin-dns-search-02.txt was posted; it is now.

This note is to kick off discussion, before, during, and after
the IETF.

A few points, few of which will be new to those who have been
following the traffic on the list of the IETF "IDN" working
group closely...


The justification for the work proposed here is that overloading
the DNS and trying to "trick" it into things that are outside
its design goals is a good way to get us into trouble, trouble
that is likely to get worse over time.  Those overloading abuses
go back to (at least) the "leaking" of DNS names into the
consciousness of end-users with the decision to include them in
URLs and the general appearances of those URLs.  They also
include efforts to use the DNS to contain the names of people,
organizations, and businesses -- whether in languages that can
be expressed in ASCII characters or otherwise.

Because the DNS has been the only tool available for these and
other purposes, we have seen the development of clever tricks --
rearranging names into different forms, encoding of other
character sets, intercepting DNS queries and transforming them
into something else, and so on-- to provide some of the needed
functionality in, more or less, the DNS framework.  Our
long-term experience with such tricks is that they don't scale
well and that they tend to develop other problems as time goes

The above issues are discussed in more detail in
draft-klensin-dns-role-01.txt; please read it.

After nearly two years of discussion in various smaller groups,
a model started to come together that was originally described
as "jack up the applications and stuff a directory layer
underneath".  That concept has proven too limiting and too
confusing in several ways, but it was a start.  The current
model is described in some detail in
draft-klensin-dns-search-02.txt (the "dns search" document).
I/we expect that anyone expecting to speak (even to raise
questions or issues) at the IRNSS session in Salt Lake City will
be throughly familiar with it, even if only to disagree.

That model assumes two "search" layers in addition to the DNS:

	* A global model based on registration of a "faceted"
	system -- including a name, location, language, and
	subject matter for the name-- and permitting fuzzy
	search on at least the name string.
	* A system of local search environments, tailored to the
	needs of a particular locale or subject matter, or
	something similar.

The model neither assumes nor depends on the identifier
definitions of the DNS nor applications that use it being
expanded.   If they are expanded (e.g., by the work of the IDN
WG), the model will use the expanded forms.  If they are not,
then the model is able to work with LDH names of the current
style, even if would be gibberish if seen by end users.

The BOF:

Given the complexity of the topic, we don't have a lot of time.
I expect to spend a few minutes reviewing the basic model and
how we got here.  If the DNS search document is clear, this will
be unlikely to introduce anything new.

We expect discussion to follow, with the following main themes:

(i) Is the model itself appropriate and, if not, how do we
quickly get to some other model?

(ii) What sorts of systems are appropriate for sublayer two and
for sublayer three?

(iii) Is there are reasonable model for locating
independently-operated servers at sublayer two and/or sublayer
three, or will some sort of global registration or allocation
scheme be needed?

Other themes within the general model, or critical of it, can be
placed on the agenda, but I expect to be warned well in advance
of the meeting that they are expected to be brought up.  And
anyone expecting to talk for more than one minute will need to
have a written summary in my hands in advance (for determination
of relevance) as well as any anticipated visual materials (so
they can be reviewed and consolidated to save time).  Anyone
having a specific proposal is expected to point to an
Internet-Draft.  If that draft is not already posted, the drafts
should be sent to me this week and their substance discussed on
this list (no surprise presentations).  Drafts that are sent to
me this week will be forwarded to the I-D submission immediately
after IETF unless updated versions are available by then.  

The intention is to get discussion, rather than presentations,
at the BOF and to base those discussions on documents already
circulated in the community.

An updated agenda will be issued this week.  Discussion topics
already on it are:

	Michael Mealling and Leslie Daigle on the SLS
	Yves Arrouye and Eric Brunner-Williams on keywords as a
	sublayer two service.
	Paul Hoffman on directory server location.

Others invited, but say something quickly -- either on this list
or to me personally.