1859 lines
40 KiB
Plaintext
1859 lines
40 KiB
Plaintext
INTERNET-DRAFT DNS Label Intelligence and Management System
|
|
UPDATES RFC 1034 February 2001
|
|
Expires August 2001
|
|
|
|
|
|
|
|
|
|
Domain Name System (DNS) DNS Label Intelligence and Management System
|
|
|
|
draft-macgowan-dnsext-label-intel-manage-00.txt
|
|
|
|
|
|
|
|
|
|
Michael L. Macgowan Jr.
|
|
|
|
|
|
Status of This Document
|
|
|
|
This draft is intended to become a Proposed Standard RFC. Distribution
|
|
of this document is unlimited. Comments should be sent to the Domain
|
|
Name Server Extensions working group mailing
|
|
list<namedroppers@ops.ietf.org> or to the author.
|
|
|
|
This document is an Internet-Draft and is in full conformance with all
|
|
provisions of Section 10 of RFC 2026. Internet-Drafts are working
|
|
documents of the Internet Engineering Task Force (IETF), its areas, and
|
|
its working groups. Note that other groups may also distribute working
|
|
documents as Internet-Drafts.
|
|
|
|
Internet-Drafts are draft documents valid for a maximum of six months
|
|
and may be updated, replaced, or obsoleted by other documents at any
|
|
time. It is inappropriate to use Internet- Drafts as reference
|
|
material or to cite them other than as "work in progress."
|
|
|
|
The list of current Internet-Drafts can be accessed at
|
|
http://www.ietf.org/ietf/1id-abstracts.txt
|
|
|
|
The list of Internet-Draft Shadow Directories can be accessed at
|
|
http://www.ietf.org/shadow.html.
|
|
|
|
|
|
|
|
Abstract
|
|
|
|
|
|
A multidimensional array of domain label analysis and extensions are
|
|
offered to overcome a number of issues with the DNS and its use to
|
|
locate resources on the Internet. These goals are accomplished by
|
|
proposing a naming convention to add labels to domain strings. The
|
|
result will be a rational relationship to the content that will provide
|
|
a method for meeting the ever-increasing need to expand the namespace,
|
|
while providing an efficient search system to access content in a user-
|
|
friendly manner.
|
|
|
|
A fundamental problem exists in the design of DNS. A user must know the
|
|
domain name including the Top Level Domain, TLD, and type the Uniform
|
|
Resource Locator, URL, accurately to connect to resources on the
|
|
Internet. The current lookup organization of the DNS uses domain labels
|
|
separated by periods to provide hierarchical levels for a resolver to
|
|
seek in finding a path to an authority. A new masking technique within
|
|
labels is proposed to accommodate lookups based on the request.
|
|
Multiple processing trees are proposed to redistribute the requests
|
|
based on the known pieces of the domain name. Rather than knowing the
|
|
fully qualified domain name, FQDN, the user can search for content
|
|
based upon known pieces of the string like group (business), country,
|
|
area code, phone number, type of organization, street address, zip code
|
|
and/or GPS location, etc.. Intelligence is added for determining the
|
|
fastest route to resolution based on user weighting, number of
|
|
requests, and traffic within the system.
|
|
|
|
A result of the masking technique is an opportunity to provide a
|
|
completely hidden label(s) for maintenance of the system. A TTL (Time
|
|
to Live), version, and type of request could be keyed into a label to
|
|
provide information, which remains with the client but is normally lost
|
|
after a request is processed. This system could be implemented to
|
|
create automatically updated records and content. Or hidden labels
|
|
could be used to distinguish between version 4 and version 6 requests
|
|
in the TCP/IP, Transmission Control Protocol/ Internet Protocol,
|
|
rollover.
|
|
|
|
Implementation of the new name system is facilitated by the addition of
|
|
a client interface for building requests. Longer domain names are
|
|
enhanced by smart AutoCompletes and group edit boxes.
|
|
|
|
Table of Contents
|
|
|
|
Status of This Document 1
|
|
Abstract 1
|
|
|
|
Table of Contents 3
|
|
|
|
1. Introduction 4
|
|
2. Inputting Request for Resolution 4
|
|
3. Resolution Processing 7
|
|
4. Processing Forest 13
|
|
5. Extended Label Uses 14
|
|
6. IANA Considerations 16
|
|
6. Security Considerations 16
|
|
|
|
References 16
|
|
|
|
Authors Address 16
|
|
Expiration and File Name 17
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1. Introduction
|
|
|
|
The Domain Name System (DNS) [RFC 1034, 1035] is the global
|
|
hierarchical replicated distributed database system for Internet
|
|
addressing, mail proxy, and other information. The DNS has been
|
|
extended to phone numbers as described in [RFC 2535]. It is designed to
|
|
accommodate a user-friendly name as an abstraction level over an IP
|
|
address, which provides a path to the physical connection to resources
|
|
and/or content on the Internet. This abstraction allows for changing
|
|
the physical location of the content without an update by the client.
|
|
The design, however, lacks a user-friendly method for assigning TLDs
|
|
and determining which TLD a content provider will be registered under.
|
|
|
|
According to COMPUTERGRAM INTERNATIONAL: January 08, 2001, over 100
|
|
million hosts are connected to the Internet with over 350 million
|
|
users. ICANN has submitted plans to increase the number of TLDs to
|
|
accommodate the lack of namespace, but the problem of organization and
|
|
extensibility continues to exist. As the number of TLDs grows, it
|
|
becomes harder for a user to input a user friendly domain name. In
|
|
essence, the user must know what derivations and which TLDs were
|
|
available to a provider at the time the organization chose a domain
|
|
name. The method of one response, in an all or nothing request, forces
|
|
precision on the part of the user that is a distraction to the original
|
|
goal of a user-friendly name. Consider a user that wants to find a new
|
|
theoretical health related company called Healthy Foods. Will the
|
|
company be called Healthyfoods.com? Or will it have an extension like
|
|
healthfoods.net, healthfoods.org, or healthfoods.health? Maybe it will
|
|
be forced to be a derivation like healthf.com, healthf.net, etc. There
|
|
is no user-friendly method to determine what the associated domain name
|
|
might be. This is a central problem of focus and organization. The
|
|
number of iterations a user must try increases with each new TLD that
|
|
is added. If a user forms multiple guesses for the TLD, excess traffic
|
|
is generated and the search is slowed by the inefficient nature of
|
|
human typing. Further, if a system were proposed under the current root
|
|
structure to allow for a search of all possible TLDs, the number of
|
|
requests would grow exponentially with the addition of each new TLD.
|
|
|
|
2. Inputting Request for Resolution
|
|
|
|
The key to making a New Name System, NNS, is to provide a user
|
|
interface, which will accommodate a friendly method of building name
|
|
requests. AutoComplete and multiple-selection drop-down, group list
|
|
boxes (some editable, some not) will make more complicated names easier
|
|
to input. Consider the previous example of Healthy Foods. Additional
|
|
extensions could be added as labels to make the namespace exponentially
|
|
larger. The web content might be reached at
|
|
www.healthy.food.US2081234567.Fairview101. In this example, www is the
|
|
Device label or content desired by the user. Health is the domain or
|
|
Subgroup/Group name label. Food is the item under the Type label.
|
|
US2081234567 is the item country/area code/number for the Global label.
|
|
Sfairview101 is the street/address of the Local label.
|
|
|
|
Derivations of this example provide a limitless expansion of the
|
|
namespace within the physical limits of the protocol. A competitor down
|
|
the block might have the same FQDN, except for the street number and
|
|
phone number e.g. www.healthy.food.US2088901234.SFairview990. A second
|
|
type of business could also be run from the same location by changing
|
|
the type e.g. www.healthy.entertainment.US2081234567.SFairview101. A
|
|
parody of the site might be offered at
|
|
www.healthy.parody.us2086669999.SState103.
|
|
|
|
A method of using less descriptive labels could also be used to
|
|
generalize the content. For example, the site for the regional office
|
|
might use only the country and area code designation e.g. .US208. A
|
|
corporate address might be located at www.healthy.food.US.corporate.
|
|
This way the Global and Local labels are not tied to physical
|
|
locations. Or there may be an 800 or 888 number that could be used for
|
|
multiple sites that are tied to multiple registrations at different
|
|
street addresses in the Local label.
|
|
|
|
The task of building these longer names with labels can be accomplished
|
|
by updating list items from the NNS and by designing a better
|
|
interface. Instead of waiting for ICANN to vote on the relative merits
|
|
of a proposal for a new TLD, items could be automatically updated and
|
|
added to the system by a list of requirements. This would force a
|
|
relationship between labels but provide a nonbiased method without
|
|
prejudice. For example, a .Bus(iness) item for the Type label would
|
|
require a copy of a business license to be granted by the governing
|
|
authorities for the area specified in the Global label or the address
|
|
specified in the Local label. A ôTMö item could separate the
|
|
Intellectual Property of Trademarks and Copyrights from other
|
|
registered listings issued from the government specified by the country
|
|
code in the Global label. Additionally, the Academy of Motion Pictures
|
|
might request an Oscar item, which would restrict membership to
|
|
nominees or recipients of the coveted award.
|
|
|
|
Just as the resolver gets an updated list of root servers upon first
|
|
connection, the resolver could also receive an updated list of items in
|
|
the Type label and return them to the client. The list could be updated
|
|
by a TTL trigger and should not be editable from the userÆs standpoint.
|
|
The user interface should allow for multiple selections, which could be
|
|
used to form separate requests for resolution. Finally, the
|
|
implementation should begin with at least a list that is equal to a
|
|
subject list found in the yellow pages of the phone book. This will
|
|
provide a well-known classification that will greatly reduce
|
|
competition for names of organizations, which are similar but provide
|
|
for very different products/services. Delta.airline is readily
|
|
distinguished from Delta.homeimprovement.
|
|
|
|
The device label would remain largely unaffected. A list of previously
|
|
connected items such as www, toasters, lock, refrigerator, etc. would
|
|
facilitate input. The list would be editable. As the number of devices
|
|
connected to the Internet grows, this method will be invaluable.
|
|
Consider mail and faxes being sent directly to
|
|
printer.mybusiness.computer.us2081234567.sfairview101. A user that
|
|
needs to send a fax to a satellite office might also be able to try
|
|
searching for mybusiness at its other street address or telephone
|
|
number eg., printer.mybusiness.computer.us714*.sPensylvaiaave2345.
|
|
Wildcards and searching are discussed in the next section.
|
|
|
|
The items under the Groups/Subgroups labels would also be a list of
|
|
previously connected to domains (less the TLD) such as sales.business
|
|
or kitchen.home. The list would contain a history of previous
|
|
connections and be editable.
|
|
|
|
The Global label would have two characters to represent the country
|
|
code followed optionally by all or part of a representative telephone
|
|
number or mask for identifying the voice number(s) associated as items
|
|
in the domain. An international code would require a rational
|
|
relationship with world organizations. The interface would contain the
|
|
country codes and/or area codes, but the numbers would have to be
|
|
added.
|
|
|
|
The Local label would require a single character to represent the type
|
|
of information presented, followed by the information in a standardized
|
|
form. The following codes are proposed for the Local label, ôPö for
|
|
Postal code, ôGö for Global Satellite Positioning and ôSö for street
|
|
address. For example, P83706 would represent the authorÆs postal code,
|
|
GP0445004N1162498 (since the ô+ö key is not valid, ôpö and ônö
|
|
represent positive and negative) would represent the GPS position of
|
|
the author with padding to standardize degrees/min/sec or SOrchard15541
|
|
would represent the Street address (house number at the end). Note each
|
|
of these would require a separate name registration. The editable list
|
|
box could be a fly out list box with one of the designators specified,
|
|
while the remainder would be user input.
|
|
|
|
+------------------+
|
|
|Street |
|
|
| Fairview101 |
|
|
State101 |
|
|
|Postal |
|
|
|GPS |
|
|
+------------------+
|
|
|
|
The added labels would exponentially expand the name space. This may
|
|
cause an undesired relation to a Global or Local designation. This
|
|
could hamper changes to an organization or business in the future.
|
|
Hence a business might want to use a CNAME entry to reference users to
|
|
a non-distinct item in a label. For instance, a corporation might want
|
|
to register mybusiness.bus.In(ternational).corporate so that the
|
|
corporate office could be used for email addresses and bookmarking.
|
|
Content might be located at each mybusiness.bus.country.location where
|
|
the company does business. This way a corporation does not have to be
|
|
penalized for moving to a new physical location. The goal of the DNS
|
|
was to remove a physical relationship to the network, but the need of
|
|
the users is for some content to have a physical relationship to the
|
|
content; which is why, in part, the NNS is proposed. The concept of an
|
|
update is also discussed in section 5.
|
|
|
|
The system would need to distinguish between the need for a request for
|
|
a connection to single IP address versus multiple requests. In an
|
|
application like a browser, traditional requests for IP resolution are
|
|
all or none. Either an IP address is connected to or not. If wildcards
|
|
are added to the request, multiple entries could be returned as a ôhitö
|
|
list. An option on the browser could determine the number of requests
|
|
specified by the user. The ôhitsö should also be weighted. For
|
|
instance, if a user wanted to find all the movie theatres in the local
|
|
area he/she might submit a request for www.*.movies.US8370*.*. She/he
|
|
would be more inclined to desire additional theatres at different
|
|
nearby area codes than derivations of different domain names or Local
|
|
label derivations for a single theatre. A simple listing of each label
|
|
with an associated numerical value in an advanced option field could
|
|
determine how the responses are weighted against one another. The NNS
|
|
could also take into account the number of requests on the system and
|
|
further limit the number of responses based upon traffic.
|
|
|
|
For registration, the content provider might want to register a more
|
|
global entry to be displayed on a restrictive search e.g. loans.US*.*.
|
|
A business content provider might want to register mybusiness.com.US*
|
|
so that requests for www.mybusiness.com.US208.* and
|
|
www.mybusiness.com.us714.* both resolve to mybusiness. A process would
|
|
have to be in place to copy an entry with wildcards to each of the
|
|
associated branches of the processing trees as discussed in section 4.
|
|
Similarly wildcard registrations should meet the rational requirements
|
|
required for the known item with the generalized scope. In the previous
|
|
example the provider would have to be licensed as a financial
|
|
institution in each of the states of the United States.
|
|
|
|
3. Resolution Processing
|
|
|
|
The key to expanding the DNS is to provide for a name space, which can
|
|
be accessed quickly and efficiently. Organization is key to this
|
|
process. The current DNS has one root organized by TLDs of the Type
|
|
label combined with Country TLDs. If a user does not know the extension
|
|
for the name, requests must be created for each one until a match is
|
|
found. The NNS creates separate roots for each label that can be used
|
|
for a search (see graphic on next page, description of TLDs is in
|
|
section 5). Instead of one tree, a forest is created, connected by a
|
|
common list of authorities for devices in the zones requested. Requests
|
|
can be organized by the known piece(s) of information. For instance, if
|
|
a user is trying to find Hewlett Packard and does not know that content
|
|
is provided at HP, a search of www.H*.*.US*.* should be returned
|
|
alphabetically from the Group label, not the Type label. However, if
|
|
the type item is known to be ôcomputerö, a search of the Type tree
|
|
would be fastest. If a user wants to find a local voice number for
|
|
Microsoft he/she could submit a request generalized request within the
|
|
local area code for www.Microsoft.software.US208*.*. The authority
|
|
would best be located by the Global processor, which might list
|
|
www.Microsoft.software.US5041234567.SState123 and
|
|
www.Microsoft.software.US5044567890.SredmondAve123. If the request for
|
|
www.Microsoft.software.US504*.* were sent to the Local processor, every
|
|
TLD would have to be queried. The result might be one phone number with
|
|
separate Local label listings for the street address, GPS, and postal
|
|
code. This would create unwanted traffic on the system.
|
|
|
|
|
|
Root ô.ö Group Root ô.öType
|
|
| |
|
|
| |
|
|
ôHö TLD TLD ôComputerö
|
|
| |
|
|
| |
|
|
--- Authority for..HP.computer.US2081234567.SChinden12----
|
|
| |
|
|
| |
|
|
ôUS208ö TLD TLD ôSChiö
|
|
| |
|
|
| |
|
|
Root ô.ö Global Root ô.öLocal
|
|
|
|
|
|
In addition to determining which label(s) to process the request, the
|
|
system would also have to take into account the weighting by the user
|
|
and the traffic on the system as discussed in the previous section.
|
|
When the FQDN is specified, the resolver would query the processor with
|
|
the fastest expected response time. A FQDN can be resolved from any of
|
|
the search processor trees. In the example
|
|
oven.macgowan.private.US2081234567.SOrchard15541, it does not matter
|
|
whether the request is sent to the Group, Type, Global, or Local
|
|
processing tree. Each leads to the authority,
|
|
macgowan.private.us2081234567.SOrchard15541.
|
|
|
|
If wildcards or null characters exist in the request, the system should
|
|
take into account the number of requests that might be generated.
|
|
Currently the DNS does not account for the ô?ö and reserves the ôö for
|
|
the root. The ô*ö could replace the singe character wildcard ô?ö and
|
|
the word ônullö could be used in lieu of ôö. The following table could
|
|
be used to determine which processing tree should be the most desirable
|
|
under such conditions:
|
|
|
|
any =
|
|
any combination of characters displayed in
|
|
request
|
|
reject=
|
|
no preferred processor
|
|
*=
|
|
match any combination of characters for
|
|
response
|
|
?=
|
|
match any single character for response
|
|
null=
|
|
no character specified
|
|
|
|
|
|
Device
|
|
Sub
|
|
Group
|
|
Type
|
|
Global
|
|
Local
|
|
Result
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
reject
|
|
*
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
reject
|
|
*
|
|
*
|
|
any
|
|
any
|
|
any
|
|
any
|
|
reject
|
|
*
|
|
*
|
|
*
|
|
any
|
|
any
|
|
any
|
|
submit to type, global, or local
|
|
processor
|
|
*
|
|
*
|
|
*
|
|
*
|
|
any
|
|
any
|
|
submit to global, or local
|
|
processor
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
any
|
|
submit to local processor
|
|
any
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
reject
|
|
any
|
|
any
|
|
*
|
|
*
|
|
*
|
|
*
|
|
reject
|
|
any
|
|
any
|
|
any
|
|
*
|
|
*
|
|
*
|
|
submit to group processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
*
|
|
*
|
|
submit to group, or type
|
|
processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
*
|
|
submit to group, type, or global
|
|
processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any
|
|
*
|
|
any
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any
|
|
*
|
|
*
|
|
any
|
|
any
|
|
any
|
|
submit to type, global, or local
|
|
processor
|
|
any
|
|
*
|
|
*
|
|
*
|
|
any
|
|
any
|
|
submit to any global, or local
|
|
processor
|
|
any
|
|
*
|
|
*
|
|
*
|
|
*
|
|
any
|
|
submit to any local processor
|
|
any
|
|
any
|
|
*
|
|
any
|
|
any
|
|
any
|
|
submit to any type, global, or
|
|
local processor
|
|
any
|
|
any
|
|
*
|
|
*
|
|
any
|
|
any
|
|
submit to any global, or local
|
|
processor
|
|
any
|
|
any
|
|
*
|
|
*
|
|
*
|
|
any
|
|
submit to any local processor
|
|
any
|
|
any
|
|
any
|
|
*
|
|
any
|
|
any
|
|
submit to any group, global, or
|
|
local processor
|
|
any
|
|
any
|
|
any
|
|
*
|
|
*
|
|
any
|
|
submit to any group, or local
|
|
processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
*
|
|
any
|
|
submit to any group, type, or
|
|
local processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
*
|
|
*
|
|
submit to any group, or type
|
|
processor
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
reject
|
|
*
|
|
any*any
|
|
any*any
|
|
any*any
|
|
any*any
|
|
any*any
|
|
reject
|
|
*
|
|
*
|
|
any*any
|
|
any*any
|
|
any*any
|
|
any*any
|
|
reject
|
|
*
|
|
*
|
|
*
|
|
any*any
|
|
any*any
|
|
any*any
|
|
submit to type, global, or local
|
|
processor
|
|
*
|
|
*
|
|
*
|
|
*
|
|
any*any
|
|
any*any
|
|
submit to global, or local
|
|
processor
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
any*any
|
|
submit to local processor
|
|
any*any
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
reject
|
|
any*any
|
|
any*any
|
|
*
|
|
*
|
|
*
|
|
*
|
|
reject
|
|
any*any
|
|
any*any
|
|
any*any
|
|
*
|
|
*
|
|
*
|
|
submit to group processor
|
|
any*any
|
|
any*any
|
|
any*any
|
|
any*any
|
|
*
|
|
*
|
|
submit to group, or type
|
|
processor
|
|
any*any
|
|
any*any
|
|
any*any
|
|
any*any
|
|
any*any
|
|
*
|
|
submit to group, type, or global
|
|
processor
|
|
any*any
|
|
any*any
|
|
any*any
|
|
any*any
|
|
any*any
|
|
any*any
|
|
reject
|
|
any*any
|
|
*
|
|
any*any
|
|
any*any
|
|
any*any
|
|
any*any
|
|
reject
|
|
any*any
|
|
*
|
|
*
|
|
any*any
|
|
any*any
|
|
any*any
|
|
submit to type, global, or local
|
|
processor
|
|
any*any
|
|
*
|
|
*
|
|
*
|
|
any*any
|
|
any*any
|
|
submit to any global, or local
|
|
processor
|
|
any*any
|
|
*
|
|
*
|
|
*
|
|
*
|
|
any*any
|
|
submit to any local processor
|
|
any*any
|
|
any*any
|
|
*
|
|
any*any
|
|
any*any
|
|
any*any
|
|
reject
|
|
any*any
|
|
any*any
|
|
*
|
|
*
|
|
any*any
|
|
any*any
|
|
submit to any global, or local
|
|
processor
|
|
any*any
|
|
any*any
|
|
*
|
|
*
|
|
*
|
|
any*any
|
|
submit to any local processor
|
|
any*any
|
|
any*any
|
|
any*any
|
|
*
|
|
any*any
|
|
any*any
|
|
reject
|
|
any*any
|
|
any*any
|
|
any*any
|
|
*
|
|
*
|
|
any*any
|
|
submit to any group, or local
|
|
processor
|
|
any*any
|
|
any*any
|
|
any*any
|
|
any*any
|
|
*
|
|
any*any
|
|
submit to any group, type, or
|
|
local processor
|
|
any*any
|
|
any*any
|
|
any*any
|
|
any*any
|
|
*
|
|
*
|
|
submit to any group, or type
|
|
processor
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
reject
|
|
*
|
|
any*
|
|
any*
|
|
any*
|
|
any*
|
|
any*
|
|
reject
|
|
*
|
|
*
|
|
any*
|
|
any*
|
|
any*
|
|
any*
|
|
reject
|
|
*
|
|
*
|
|
*
|
|
any*
|
|
any*
|
|
any*
|
|
reject
|
|
*
|
|
*
|
|
*
|
|
*
|
|
any*
|
|
any*
|
|
submit to global, or local
|
|
processor
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
any*
|
|
submit to local processor
|
|
any*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
reject
|
|
any*
|
|
any*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
reject
|
|
any*
|
|
any*
|
|
any*
|
|
*
|
|
*
|
|
*
|
|
reject
|
|
any*
|
|
any*
|
|
any*
|
|
any*
|
|
*
|
|
*
|
|
reject
|
|
any*
|
|
any*
|
|
any*
|
|
any*
|
|
any*
|
|
*
|
|
reject
|
|
any*
|
|
any*
|
|
any*
|
|
any*
|
|
any*
|
|
any*
|
|
reject
|
|
any*
|
|
*
|
|
any*
|
|
any*
|
|
any*
|
|
any*
|
|
reject
|
|
any*
|
|
*
|
|
*
|
|
any*
|
|
any*
|
|
any*
|
|
submit to type, global, or local
|
|
processor
|
|
any*
|
|
*
|
|
*
|
|
*
|
|
any*
|
|
any*
|
|
submit to any global, or local
|
|
processor
|
|
any*
|
|
*
|
|
*
|
|
*
|
|
*
|
|
any*
|
|
submit to any local processor
|
|
any*
|
|
any*
|
|
*
|
|
any*
|
|
any*
|
|
any*
|
|
reject
|
|
any*
|
|
any*
|
|
*
|
|
*
|
|
any*
|
|
any*
|
|
submit to any global, or local
|
|
processor
|
|
any*
|
|
any*
|
|
*
|
|
*
|
|
*
|
|
any*
|
|
submit to any local processor
|
|
any*
|
|
any*
|
|
any*
|
|
*
|
|
any*
|
|
any*
|
|
reject
|
|
any*
|
|
any*
|
|
any*
|
|
*
|
|
*
|
|
any*
|
|
submit to any group, or local
|
|
processor
|
|
any*
|
|
any*
|
|
any*
|
|
any*
|
|
*
|
|
any*
|
|
reject
|
|
any*
|
|
any*
|
|
any*
|
|
any*
|
|
*
|
|
*
|
|
submit to any group, or type
|
|
processor
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
?any
|
|
?any
|
|
?any
|
|
?any
|
|
?any
|
|
?any
|
|
reject
|
|
?any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
reject
|
|
?any
|
|
?any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
reject
|
|
?any
|
|
?any
|
|
?any
|
|
any
|
|
any
|
|
any
|
|
submit to type, global, or local
|
|
processor
|
|
?any
|
|
?any
|
|
?any
|
|
?any
|
|
any
|
|
any
|
|
submit to global, or local
|
|
processor
|
|
?any
|
|
?any
|
|
?any
|
|
?any
|
|
?any
|
|
any
|
|
submit to local processor
|
|
any
|
|
?any
|
|
?any
|
|
?any
|
|
?any
|
|
?any
|
|
reject
|
|
any
|
|
any
|
|
?any
|
|
?any
|
|
?any
|
|
?any
|
|
reject
|
|
any
|
|
any
|
|
any
|
|
?any
|
|
?any
|
|
?any
|
|
submit to group processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
?any
|
|
?any
|
|
submit to group, or type
|
|
processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
?any
|
|
submit to group, type, or global
|
|
processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any
|
|
?any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any
|
|
?any
|
|
?any
|
|
any
|
|
any
|
|
any
|
|
submit to type, global, or local
|
|
processor
|
|
any
|
|
?any
|
|
?any
|
|
?any
|
|
any
|
|
any
|
|
submit to any global, or local
|
|
processor
|
|
any
|
|
?any
|
|
?any
|
|
?any
|
|
?any
|
|
any
|
|
submit to any local processor
|
|
any
|
|
any
|
|
?any
|
|
any
|
|
any
|
|
any
|
|
submit to any type, global, or
|
|
local processor
|
|
any
|
|
any
|
|
?any
|
|
?any
|
|
any
|
|
any
|
|
submit to any global, or local
|
|
processor
|
|
any
|
|
any
|
|
?any
|
|
?any
|
|
?any
|
|
any
|
|
submit to any local processor
|
|
any
|
|
any
|
|
any
|
|
?any
|
|
any
|
|
any
|
|
submit to any group, global, or
|
|
local processor
|
|
any
|
|
any
|
|
any
|
|
?any
|
|
?any
|
|
any
|
|
submit to any group, or local
|
|
processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
?any
|
|
any
|
|
submit to any group, type, or
|
|
local processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
?any
|
|
?any
|
|
submit to any group, or type
|
|
processor
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
any?any
|
|
any?any
|
|
any?any
|
|
any?any
|
|
any?any
|
|
any?any
|
|
reject
|
|
any?any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any?any
|
|
any?any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any?any
|
|
any?any
|
|
any?any
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any?any
|
|
any?any
|
|
any?any
|
|
any?any
|
|
any
|
|
any
|
|
submit to global, or local
|
|
processor
|
|
any?any
|
|
any?any
|
|
any?any
|
|
any?any
|
|
any?any
|
|
any
|
|
submit to local processor
|
|
any
|
|
any?any
|
|
any?any
|
|
any?any
|
|
any?any
|
|
any?any
|
|
reject
|
|
any
|
|
any
|
|
any?any
|
|
any?any
|
|
any?any
|
|
any?any
|
|
reject
|
|
any
|
|
any
|
|
any
|
|
any?any
|
|
any?any
|
|
any?any
|
|
submit to group processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any?any
|
|
any?any
|
|
submit to group, or type
|
|
processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any?any
|
|
submit to any processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any
|
|
any?any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any
|
|
any?any
|
|
any?any
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any
|
|
any?any
|
|
any?any
|
|
any?any
|
|
any
|
|
any
|
|
submit to any global, or local
|
|
processor
|
|
any
|
|
any?any
|
|
any?any
|
|
any?any
|
|
any?any
|
|
any
|
|
submit to any local processor
|
|
any
|
|
any
|
|
any?any
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any
|
|
any
|
|
any?any
|
|
any?any
|
|
any
|
|
any
|
|
submit to any global, or local
|
|
processor
|
|
any
|
|
any
|
|
any?any
|
|
any?any
|
|
any?any
|
|
any
|
|
submit to any local processor
|
|
any
|
|
any
|
|
any
|
|
any?any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any
|
|
any
|
|
any
|
|
any?any
|
|
any?any
|
|
any
|
|
submit to any group, or local
|
|
processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any?any
|
|
any
|
|
submit to any processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any?any
|
|
any?any
|
|
submit to any group, or type
|
|
processor
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
any?
|
|
any?
|
|
any?
|
|
any?
|
|
any?
|
|
any?
|
|
reject
|
|
any?
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any?
|
|
any?
|
|
any
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any?
|
|
any?
|
|
any?
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any?
|
|
any?
|
|
any?
|
|
any?
|
|
any
|
|
any
|
|
submit to any processor
|
|
any?
|
|
any?
|
|
any?
|
|
any?
|
|
any?
|
|
any
|
|
submit to any processor
|
|
any
|
|
any?
|
|
any?
|
|
any?
|
|
any?
|
|
any?
|
|
submit to any processor
|
|
any
|
|
any
|
|
any?
|
|
any?
|
|
any?
|
|
any?
|
|
submit to any processor
|
|
any
|
|
any
|
|
any
|
|
any?
|
|
any?
|
|
any?
|
|
submit to any processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any?
|
|
any?
|
|
submit to any processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any?
|
|
submit to any processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any
|
|
any?
|
|
any
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any
|
|
any?
|
|
any?
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any
|
|
any?
|
|
any?
|
|
any?
|
|
any
|
|
any
|
|
submit to any processor
|
|
any
|
|
any?
|
|
any?
|
|
any?
|
|
any?
|
|
any
|
|
submit to any processor
|
|
any
|
|
any
|
|
any?
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any
|
|
any
|
|
any?
|
|
any?
|
|
any
|
|
any
|
|
submit to any processor
|
|
any
|
|
any
|
|
any?
|
|
any?
|
|
any?
|
|
any
|
|
submit to any processor
|
|
any
|
|
any
|
|
any
|
|
any?
|
|
any
|
|
any
|
|
submit to any processor
|
|
any
|
|
any
|
|
any
|
|
any?
|
|
any?
|
|
any
|
|
submit to any processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any?
|
|
any
|
|
submit to any processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any?
|
|
any?
|
|
submit to any processor
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Null
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
not valid
|
|
any
|
|
Null
|
|
any
|
|
any
|
|
any
|
|
any
|
|
submit to any processor
|
|
any
|
|
any
|
|
Null
|
|
any
|
|
any
|
|
any
|
|
reject
|
|
any
|
|
any
|
|
any
|
|
Null
|
|
any
|
|
any
|
|
submit to group, global, local
|
|
processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
Null
|
|
any
|
|
submit to group, type, local
|
|
processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
any
|
|
Null
|
|
submit to group, type, global
|
|
processor
|
|
Null
|
|
Null
|
|
any
|
|
any
|
|
any
|
|
any
|
|
not valid
|
|
any
|
|
Null
|
|
Null
|
|
any
|
|
any
|
|
any
|
|
reject
|
|
any
|
|
any
|
|
Null
|
|
Null
|
|
any
|
|
any
|
|
submit to global, local
|
|
processor
|
|
any
|
|
any
|
|
any
|
|
Null
|
|
Null
|
|
any
|
|
submit to group, local
|
|
processor
|
|
any
|
|
any
|
|
any
|
|
any
|
|
Null
|
|
Null
|
|
submit to group, type
|
|
processor
|
|
Null
|
|
Null
|
|
Null
|
|
any
|
|
any
|
|
any
|
|
not valid
|
|
any
|
|
Null
|
|
Null
|
|
Null
|
|
any
|
|
any
|
|
submit to global, local
|
|
processor
|
|
any
|
|
any
|
|
Null
|
|
Null
|
|
Null
|
|
any
|
|
submit to local processor
|
|
any
|
|
any
|
|
any
|
|
Null
|
|
Null
|
|
Null
|
|
submit to group processor
|
|
Null
|
|
Null
|
|
Null
|
|
Null
|
|
any
|
|
any
|
|
not valid
|
|
any
|
|
Null
|
|
Null
|
|
Null
|
|
Null
|
|
any
|
|
submit to local processor
|
|
any
|
|
any
|
|
Null
|
|
Null
|
|
Null
|
|
Null
|
|
not valid
|
|
Null
|
|
Null
|
|
Null
|
|
Null
|
|
Null
|
|
any
|
|
not valid
|
|
any
|
|
Null
|
|
Null
|
|
Null
|
|
Null
|
|
Null
|
|
not valid
|
|
Null
|
|
Null
|
|
Null
|
|
Null
|
|
Null
|
|
Null
|
|
not valid
|
|
|
|
|
|
|
|
4. Processing Forest
|
|
|
|
|
|
|
|
|--Group Root---|
|
|
| |
|
|
|---Type Root---|
|
|
| |
|
|
client->------Resolver ->------| |----Authority->---
|
|
return
|
|
| |
|
|
|--Global Root--|
|
|
| |
|
|
|--Local Root---|
|
|
|
|
Once the resolver has determined which root to send the resolution
|
|
request to, each tree should be organized according to an exhaustive
|
|
replication of each name string on the route to an authority. For
|
|
instance, the Group tree would be organized alphabetically with TLDs
|
|
ôAö through ôZö initially. Since there are a lot of organizations with
|
|
business name derivations using the word ômicronö, there might be a
|
|
need to reorganize the ôMö TLD to accommodate a ôMicö and a ôMidö TLD.
|
|
Although it would be more efficient to break down each letter according
|
|
to the demands of the system, it would be easier to specify one mask
|
|
for the entire tree. The number of TLDs becomes a function of the
|
|
permutations of the number of masked characters in the available set of
|
|
usable characters rather than a select few that are added over time.
|
|
The resolver can cache the TLDs and know when to use them based upon
|
|
the mask for the tree. If a larger mask is needed to further distribute
|
|
the load, the resolvers would have to be updated.
|
|
|
|
To replicate the current DNS entries under the additional labels
|
|
specified in this proposal a number of applications and uses would have
|
|
to be accounted for. The ARPA listings would remain unchanged or they
|
|
could be replicated under each root by recombining telephone numbers in
|
|
a single label under the e164 or padding IP addresses under the inverse
|
|
lookup tables without the periods separating the octets.
|
|
|
|
Since the NNS uses a forest of processing trees and the current system
|
|
uses only one tree, a conversion process would have to be developed to
|
|
distinguish between DNS requests and NNS requests. This could be
|
|
handled using a number of different methods.
|
|
|
|
A version flag in the request could accomplish this. This way the
|
|
resolver would be able to determine which searchable labels were used
|
|
and the order of presentation by standardization. The resolver
|
|
intelligence would know which labels to use for lookup or in the
|
|
preferred embodiment. The resolver could also reorganize the labels to
|
|
be presented under the correct processor so that the Global label is
|
|
presented at the right of the name string for processing through the
|
|
Global tree. Legacy requests without a version would be sent to the
|
|
Type tree.
|
|
|
|
Another method could accomplish the goal by combining the labels the
|
|
request for the processing tree. In the previous example, the request
|
|
oven.macgowan.private.US2081234567.SOrchard15541 could be recombined by
|
|
the submitting processor as
|
|
oven.macgowanUS2081234567SOrchard15541.private to be searched under the
|
|
Type tree. Similarly it could be recombined as
|
|
oven.macgowanprivateUS2081234567.SOrchard15541 to be searched under the
|
|
Local tree. If a legacy DNS based system submitted a request for
|
|
www.yahoo.com, it might be appended as www.yahoo.com..... The first ô.ö
|
|
after com is to end the Type label. The second ô.ö Represents the null
|
|
character at the end of the Global label. The third ô.ö is for the
|
|
Local label. The fourth ô.ö is for the root. The last ô.ö is for the
|
|
end of the sentence. If applications are affected by the reservation of
|
|
the ô.ö for the root, the request could be recreated as
|
|
www.yahoo.com.null.null..
|
|
|
|
A final method is to create a hidden label. Hidden labels are discussed
|
|
further in extended label uses.
|
|
|
|
Once the authority for a label is found within the label, the system
|
|
must also determine if there are Subgroups. Subgroups can be used for a
|
|
number of internal functions and/or divisions within the authority for
|
|
an organization. At this point the system would continue to resolve
|
|
using subgroup labels as levels as it does under the current system
|
|
toward the device at the left of the name string.
|
|
|
|
The remaining searchable labels would be serviced using a similar
|
|
method. The Type tree would be organized as it is in the DNS with TLDs
|
|
representing each item in the list. Since the items in the list are
|
|
limited by the system, the mask could be set to none. The Global label
|
|
should be organized by a mask, which would accommodate at least the
|
|
country and area codes. The Local label would mask the PGS items until
|
|
enough TLDs are derived to equal processing traffic under the other
|
|
trees. Provisions should be made for the non-distinct items like
|
|
ôcorporateö that may use characters not reserved for physical
|
|
locations. In addition, a null TLD could be used to organize the
|
|
remainder of name strings that have omitted labels. The null ôö
|
|
character or the word ônullö could be used to represent legacy DNS
|
|
strings under the new labels until the name strings are updated with
|
|
the longer requirements.
|
|
|
|
The NNS allows a FQDN to be resolved from each searchable label. Please
|
|
refer to the previous example,
|
|
oven.macgowan.private.US2081234567.SOrchard15541. The authority,
|
|
ôMacgowan.private.US2081234567.SOrchard15541ö is found using the
|
|
traditional method of the DNS using a Type item of ôprivateö (mask of
|
|
zero). The authority, ôMacgowan.private.US2081234567.SOrchard15541ö is
|
|
found through the Group processor under the ôMacö branch using a mask
|
|
of three characters. The ôMacgowan.private.US2081234567.SOrchard15541ö
|
|
authority is found under ôUS208ö using a mask of four characters within
|
|
the Global processing tree. The
|
|
ôMacgowan.private.US2081234567.SOrchard15541ö authority is also found
|
|
under ôSOrö of the branch masked under the Local tree.
|
|
|
|
5. Extended Label Uses
|
|
|
|
The NNS is a simple design which can accommodate the future of Internet
|
|
name strings by incorporating additional processing trees and a large
|
|
name space organized by labels with a user friendly interface. A search
|
|
engine is automatically derived from the organization within labels as
|
|
opposed to across labels. In other words, you send the known pieces of
|
|
the request to the processing tree that will yield the quickest results
|
|
with the least amount of traffic. Once names are bookmarked or selected
|
|
from a list of AutoCompletes, requests can be sent to any processing
|
|
tree to balance the load on the system.
|
|
|
|
The present proposal also provides an extensible path for future labels
|
|
that may or may not have associated processors. A ôContactö label
|
|
might always be masked during the request for resolution, but provide
|
|
additional value to the user with a description about the connection or
|
|
a webmasterÆs email address. This has extreme value in the event a name
|
|
can be resolved, but not reached by connection to the IP address. In
|
|
addition to adding new labels, a group or association might request a
|
|
new item under the Type label or a new area code might be added under
|
|
the Group label. Therefore, one result of this system is a combination
|
|
of devices and labels which expands exponentially to meet the demand
|
|
for namespace with an inherent capability to adjust to future needs.
|
|
|
|
An additional hidden label (mask of all) adjacent to the root could be
|
|
hidden and give information for maintenance of the system and/or the
|
|
listing. The most important consideration is keying the order and
|
|
number of labels in the string. Or using this method, a hidden security
|
|
label could help create a firewall between valid requests from users in
|
|
the domain versus outsiders or tie to a public key for the destination.
|
|
The hidden label could also be used to pass a request for content
|
|
delivered in a specific language. With the addition of the Local and
|
|
Global labels it might also be necessary to add a TTL label which could
|
|
serve as a timer for the registration or the life of a bookmark or
|
|
connection. The client could use this value in a history of valid
|
|
connections to make a request for an updated TTL, a new IP address,
|
|
and/or a trigger for replacing the name with a new string. This would
|
|
allow for a change in address, phone number, new area code, etc. on the
|
|
part of the provider. Just as the domain name was an abstraction layer
|
|
over the IP address, the current domain string is an abstraction for a
|
|
future domain string. A routine could prompt a user to change an entry
|
|
in a contact/bookmark list. Services such as WWW could also
|
|
automatically update links in the content or reflect changes to related
|
|
destinations within the content. In use, the client could compare its
|
|
value to the value at the authority. If the authority has a value of
|
|
zero, the client would update its name and IP address to the new
|
|
pointer returned by the resolver. An electronically updating NNS with
|
|
updating links in content is a product of this system.
|
|
|
|
An example of using this procedure could be applied to finding the best
|
|
cell phone plan. A user buys a cell plan. The user emails contact links
|
|
to friends and associates. The recipients use their link to dial the
|
|
user. The user determines a new provider would be more advantageous and
|
|
purchases a new plan with a new number. The user sets their old TTL to
|
|
zero in the NNS and creates a new FQDN with the new cell number. Now
|
|
when the recipients use the old string, they are pointed to the new
|
|
string. The string with the new number is updated in the recipientÆs
|
|
contact list. The user is not tied to their telephone number and the
|
|
recipients do not need to manually adjust their entries.
|
|
|
|
Hidden labels and masking would also have to be present at the client.
|
|
A business might have a lot of phone numbers or locations listed on the
|
|
name servers but use a shorter version of the string for making local
|
|
connections. This way all the devices under a group could be combined
|
|
as a single domain name. The future direction of label intelligence and
|
|
the ideas expressed here suggest that there may be numerous ways to
|
|
provide abstraction levels within the label string. Even the IP address
|
|
might be used as an identifier to search for the rest of the domain
|
|
string or an item like the telephone number.
|
|
|
|
6. IANA Considerations
|
|
|
|
The focus of the IANA will change considerably. The need to regulate
|
|
name hoarders, TM infringement considerations, and the decision to
|
|
implement new TLDs will be greatly reduced. The IANA might be used to
|
|
determine the relationships between labels as new items are added under
|
|
the requirements that provide for fair and equal addition to the Type
|
|
label.
|
|
|
|
7. Security Consideration
|
|
|
|
Name resolution is an inherent problem for spoofing content, but is
|
|
beyond the scope of this proposal. The suggested ability to update name
|
|
strings at the client also increases the need to provide secure
|
|
communications between the system and the client.
|
|
|
|
|
|
References
|
|
|
|
|
|
|
|
[RFC 1034] - "Domain names - concepts and facilities", P.
|
|
|
|
Mockapetris, 11/01/1987.
|
|
|
|
[RFC 1035] - "Domain names - implementation and specification", P.
|
|
|
|
Mockapetris, 11/01/1987.
|
|
|
|
[RFC 2535] û ôE.164 number and DNSö , P.
|
|
|
|
P. Faltstrom, 9/1/2000.
|
|
|
|
Authors Address
|
|
|
|
Michael L. Macgowan Jr.
|
|
15541 Orchard Ave.
|
|
Caldwell, ID 83607 USA
|
|
|
|
|
|
Telephone: +1 208.454.1177 (h)
|
|
FAX: +1 208.455.0439
|
|
EMail: mmacgowa@yahoo.com
|
|
|
|
|
|
Expiration and File Name
|
|
|
|
This draft expires in August 2001
|
|
|
|
Its file name is labelmanage.txt
|
|
|
|
Full Copyright Statement
|
|
|
|
Copyright (C) The Internet Society (February 2001). All Rights
|
|
Reserved.
|
|
|
|
This document and translations of it may be copied and furnished to
|
|
others, and derivative works that comment on or otherwise explain it or
|
|
assist in its implementation may be prepared, copied, published and
|
|
distributed, in whole or in part, without restriction of any kind,
|
|
provided that the above copyright notice and this paragraph are
|
|
included on all such copies and derivative works. However, this
|
|
document itself may not be modified in any way, such as by removing the
|
|
copyright notice or references to the Internet Society or other
|
|
Internet organizations, except as needed for the purpose of developing
|
|
Internet standards in which case the procedures for copyrights defined
|
|
in the Internet Standards process must be followed, or as required to
|
|
translate it into languages other than English.
|
|
|
|
The limited permissions granted above are perpetual and will not be
|
|
revoked by the Internet Society or its successors or assigns. This
|
|
document and the information contained herein is provided on an "AS IS"
|
|
basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE
|
|
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED
|
|
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
|
|
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
|
|
FITNESS FOR A PARTICULAR PURPOSE."
|
|
Michael L. Macgowan Jr. February 2001 [Page 6]
|
|
|
|
Internet Draft DNS Label Intelligence and Management System
|
|
|
|
|
|
|