Re: Name lookup service
John C Klensin <klensin@jck.com> Thu, 06 December 2001 18:51 UTC
Return-Path: <ietf-irnss-errors@lists.elistx.com>
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id
<0GNX00804R1YY5@eListX.com> (original mail from klensin@jck.com);
Thu, 06 Dec 2001 13:51:34 -0500 (EST)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025
#44856) id <0GNX00801R1XY3@eListX.com> for ietf-irnss@elist.lists.elistx.com
(ORCPT ietf-irnss@lists.elistx.com); Thu, 06 Dec 2001 13:51:33 -0500 (EST)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025
#44856) id <0GNX00801R1XY2@eListX.com> for ietf-irnss@elist.lists.elistx.com
(ORCPT ietf-irnss@lists.elistx.com); Thu, 06 Dec 2001 13:51:33 -0500 (EST)
Received: from bs.jck.com ([209.187.148.211]) by eListX.com (PMDF V6.0-025
#44856) with ESMTP id <0GNX007A6R1WL5@eListX.com> for
ietf-irnss@lists.elistx.com; Thu, 06 Dec 2001 13:51:32 -0500 (EST)
Received: from [209.187.148.217] (helo=P2) by bs.jck.com with esmtp (Exim 3.22
#1) id 16C3YS-000H2r-00; Thu, 06 Dec 2001 18:47:32 +0000
Date: Thu, 06 Dec 2001 13:47:31 -0500
From: John C Klensin <klensin@jck.com>
Subject: Re: Name lookup service
In-reply-to: <20011207014612.G29209@spsoft.co.kr>
To: YangWoo Ko <newcat@spsoft.co.kr>, ietf-irnss@lists.elistx.com
Cc: keyword@iak.ne.kr
Message-id: <128446147.1007646451@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
References: <20011207014612.G29209@spsoft.co.kr>
List-Owner: <mailto:ietf-irnss-help@lists.elistx.com>
List-Post: <mailto:ietf-irnss@lists.elistx.com>
List-Subscribe: <http://lists.elistx.com/ob/adm.pl>,
<mailto:ietf-irnss-request@lists.elistx.com?body=subscribe>
List-Unsubscribe: <http://lists.elistx.com/ob/adm.pl>,
<mailto:ietf-irnss-request@lists.elistx.com?body=unsubscribe>
List-Archive: <http://lists.elistx.com/archives/ietf-irnss>
List-Help: <http://lists.elistx.com/elists/admin.shtml>,
<mailto:ietf-irnss-request@lists.elistx.com?body=help>
List-Id: <ietf-irnss.lists.elistx.com>
Hi. I found this very helpful. I would like to see something of this type made more widely available. A few general observations follow. I assume you have looked at the long note with subject "Keywords, direct navigation, and search layer 2..." I just sent to Yves -- it covers some of the same ground and I should not repeat myself. And I will use the notation I introduced there (although I may change my mind about notation by Monday). As far as Monday is concerned, the policy remains "no presentations or extended document reviews". If, after reading what follows, you think it would be useful to introduce a specific discussion on this topic, I will give you time, but on the two conditions discussed earlier: (i) you should assume in your presentation that the people in the audience have read these notes and any updated documents you post in the meantime. Anyone who comes unprepared is going to be lost in this BOF, and that is, as we say, considered a feature. (ii) the document needs to be revised into Internet-Draft format and made available so that it can be posted as an I-D immediately after IETF. In practice, that means I need it in my hands this weekend. But my impression is that you will be able to help us understand things as well by commenting on Yves' discussion, and that will require less short-notice preparation on your part. General suggestion about the document. As I read it, I see several things that appear to me to be user interface design issues and others that are clear, on-the-wire, protocol issues. It would be useful --to the IETF and, I believe, in your own context-- if you would separate the two. If nothing else, putting them together results in document that is an odd mix between a statement of "requirements" and a description of a particular system design. Also, please look at "dns-search-02". I have changed my mind about many things since -00 was written, and several of those changes have been motivated by comments from your colleagues in Korea. -02 also has much better explanations of some of the concepts although, as Nico, Yves, and I have been finding out, it still is not good enough. Specific comments below. --On Friday, 07 December, 2001 01:46 +0900 YangWoo Ko <newcat@spsoft.co.kr> wrote: > Requirements for Name Lookup Service - Draft > > MINC-KR Meeting > July 16, 2001 [...] > Internet address has been evolved in a way that users can use > it conveniently. The IP address is the first implementation > of the Internet address. Raw numbers are used to represent > subnets and hosts in which they are separated by dots. The > DNS and IDN replaced the numbers of the IP address with > character strings in which they are more easily identifiable > by users. I think it would be helpful were you a bit more precise here. It was recognized early in the ARPANET period that we needed to give things names, and that those names would accomplish (at least) two separate purposes -- ease of use by people and some reference portability as network topology changed and hosts were renumbered. That portability issue makes it incorrect to refer to DNS names (internationalized or otherwise) as "addresses". They are really a reference to an address (or other resource or target). For this reason, I would strongly advise you against _storing_ IP addresses in your databases. The ability of the DNS to support a constant name or URL even while the underlying address changes, and to do so with appropriate data lifetime mechanisms, is very important to Internet operations. Of course, what is cached (consistent with DNS TTL rules) and what is delivered to the user (see the discussion in "dns search" about whether the user-level applicatio should call the search mechanism and then the DNS, or whether the DNS name should be resolved by the search mechanism) is another issue, one that should be determined by your requirements and design. > Despite the convenience of DNS and IDN, there are still needs > to identify or "lookup" the Internet object by "name". The > names include domain names, common names such as personal > names and business names, for examples. A context dependent > name identifies uniquely only one Internet resource. Name > lookup service returns just one result for one query. > > CNRP and directory system were also developed to support > various needs on domain names. However, they are NOT regarded > as a name lookup service because they are designed to return > multiple returns for one input. I am trying to drop the word "directory" from my vocabulary in this context, since it means so many different things to different people. And you have just identified one of the reasons why I'm not sure that CNRP, as now defined, is really the right model for the functions defined in "dns-search". [...] > 3.1 Return 0 or 1 result > > Since the name lookup service is based on the lookup > repository that is defined in [1], the result to a successful > lookup is a single group of information. That lookup > repository contains many types of address information. The > group of information, the result of the lookup operation, > includes IP address, domain name, URL, e-mail address and so > on. It needs more discussion about which attributes should be > included. It also needs more discussion whether the result is > one specific attribute or multiple attributes of the target > Internet object. I would like to understand this, and your evolving thinking, better. But my note to Nico explained (I hope) how one can model lookup systems of this variety within the sublayer 2 "dns search" model. > 3.2 Input is a word or a phrase > > One of the main purposes of the name lookup services is to > allow users to use more intuitive and familiar names. In this > sense, the services should permit the use of phrases as well > as the words. These names can be in all languages. Further > discussion includes the maximum words in a phrase, the length > of a phrase, whether permitting special characters (i.e., > slash, comma, blank space, parenthesis, and so on) as part of > the input. Yes. Once the DNS constraints are removed, all of this becomes easier to think about. Or, more specifically, we can focus more on what is needed, rather than on what the DNS (reasonably) permits. > 3.3 No explicit attribute > > Users provide only the naming attribute of the object that > they want to find. No other attributes of the object are > required explicitly from users. Instead, the implicit use of > attributes of the name is permitted for the sake of > efficiency and flexibility. This will be discussed in Section > 3.4. > > 3.4 User profile may be provided (optional) > > As mentioned in Section 3.2, some attributes are used to > efficiently handle the name lookup services. For instance, > the following attributes could be used in user's profile. > > * The language > * The locality (or preference location) > * The name lookup service provider I think this is a user interface issue. Certainly, nothing in the "dns search" model requires that all of the information specified in a query to the system be supplied by the user (each time, or at any time). Whereever the inforation comes from, unconstrainted database search is typically slow and expensive, unless the database is somewho kept small. Your "DoS attack" notes pointed this out very well. > In addition to the attributes listed above, the current > location of mobile terminal might be an important attribute > in mobile Internet environments. I agree, although the "location" of a roaming mobile device is a bit of a nightmare with regard to both granularity and the way in which location is expressed. I still hope that someone --smarter than I am-- will fill in enough of the hints about "network location" in the "dns search" document to make that idea viable. > Consequently, the name > lookup services can provide a context-sensitive service that > can enhance user's convenience. Moreover the name lookup > services can enlarge the limitation of the DNS naming space > by using context-sensitive naming scheme. Again, I think we are in general agreement, but that it would be helpful to explore the details of these notions, especially with regard to scaling to large-scale databases and operations. > 3.5 Auto completion (optional) > > In order to reduce the query error by typing incorrect names, > the service can complete the full names by matching them > partially even before finishing typing while users type names.
- Re: Name lookup service John C Klensin
- Name lookup service YangWoo Ko