From: Leslie Daigle <leslie@thinkingcat.com>
Date: sön nov 18, 2001 22:19:22 Europe/Stockholm
To: Patrik Fältström <paf@cisco.com>
Cc: iab@ietf.org, IESG <iesg@ietf.org>
Subject: Re: Informational RFC to be:
draft-irtf-idrm-handle-system-03.txt (fwd)
Howdy,
By the way, this is one of a series of 3 documents; the other two
draft-irtf-idrm-handle-system-def-01.txt
draft-irtf-idrm-handle-system-protocol-01.txt
define the more detailed mechanics. Is the expectation that they
will
also be published as Informational?
So, I wasn't entirely sure how to frame my remarks... if you look
at this document in isolation, it is a reasonable technical
presentation
of an alternative naming system developed quite independently of
IETF
efforts, within a single organization, which exposes some design
choices
not documented elsewhere. I've included more detailed critiquing
remarks
below my sig line, and I'll note that it doesn't actually _lie_
about
its relationship to IETF work, but there are some significant
holes.
As an individual submission, we've published lesser things.
However, considered as an IRTF document, I have to ask myself:
what
is the point of the IRTF research group publishing a proposal that
is
literally divorced from all work done in the IETF for the last 6
years?
This document correctly notes that the proposal is different from
URNs,
LDAP and DNS, but it doesn't particularly justify why it is more
applicable to the DRM problem. I would somehow expect that as a
product
of the RG.
Although it's not particularly germane to the publish/don't publish
question, I've tried to express, in my more detailed remarks, some
of
the areas in which I think the proposal is technically weak, or at
least as-yet-unjustified.
Some historical background for those who don't know: Handles were
originally one of the proposals for THE URN standard. When the URN
WG
was formed around the framework that would support multiple naming
systems, the CNRI folk withdrew and continued developing their own
system.
That's fine, except that this work, though as old as the IETF URN
material,
has not been shaken down in a cross-area discussion, and it
hasn't grown from the use of any of the general design trends
within the IETF.
Finally, when I first looked at this document, I picked up the
phone
and called Thomas Hardjono (co-chair of the IDRM research group).
I asked him the same question as above, and I will forward these
remarks for his consideration in the context of the rg.
Leslie.
Patrik Fältström wrote:
Leslie, can you please check this document for me? I know you are
keen on
seeing that descriptions of the Handle system is in sync with the
URN work.
IESG: Leslie and myself are in complete agreement that the handle
system
make a perfect URN namespace. But, certain "inventors" have a view
which is
close to what Tim has about URL's. "They can be persistent if only
the
owner make that decision". We don't think that is enough.
Because of this, I am happy to delegate reading of this document
as
Area
Director for Apps Area to the wg chair of the URN wg. :-)
paf
---------- Forwarded Message ----------
Date: fredag 2 november 2001 19.17 +0000
From: RFC Editor <rfc-ed@ISI.EDU>
To: iesg@ietf.org
Subject: Informational RFC to be:
draft-irtf-idrm-handle-system-03.txt
IESG,
This RFC-to-be was submitted to the RFC Editor to be published as
Informational: draft-irtf-idrm-handle-system-03.txt.
Four week timeout is initiated (30 November 2001).
Handle System Overview
The Handle System is a general-purpose global name service that
allows
secured name resolution and administration over the public
Internet.
The Handle System manages handles, which are unique names for
digital
objects and other Internet resources. This document provides an
overview of the Handle System in terms of its namespace and
service
architecture, as well as its relationship to other Internet
services
such as DNS, LDAP/X.500, and URN.
Sincerely,
Sandy Ginoza - USC/ISI
Request for Comments Documents
Voice: (310) 822-1511 x89369
Fax: (310) 823-6714
EMAIL: RFC-ED@RFC-EDITOR.ORG
---------- End Forwarded Message ----------
--
------------------------------------------------------------------ -
"An essential element of a successful journey
is recognizing when you have arrived."
-- ThinkingCat
Leslie Daigle
leslie@thinkingcat.com
------------------------------------------------------------------ -
Detailed comments on draft-irtf-idrm-handle-system-03.txt:
From here:
1. Introduction
to here:
for general purpose resource naming. An additional factor which
argues
we have several paragraphs of useful exposition on the creation of
a particular federated naming system, and some of the design
choices
therein. Fine.
This:
against using DNS as a general purpose naming system is the DNS
administrative model. DNS names are typically managed by the
network
administrator(s) at the DNS zone level, with no provision for a
per
name
administrative structure, and no facilities for anyone other than
network administrators to create or manage names. This is
appropriate
for domain name administration but less so for general purpose
resource
name administration. The Handle System has been designed from the
start
to serve as a naming system for very large numbers of entities and
to
allow administration at the name level. The handle system data
model
allows access control to be defined at the level of each handle
data.
Each handle can further define its own administrator(s) to manage
the
handle data via the handle system authentication protocol.
is mostly true, although it implies that the choice is either to
store
all data in the DNS or none of it.
While this:
URLs (Uniform Resource Locators) [4] allow certain Internet
resources
to be named as a combination of a DNS name and local name. The
local
name may be a local file path, or a reference to some local
service,
e.g. a cgi-bin script. This combination of DNS name and local name
provides a flexible administrative model for naming and managing
individual Internet resources. There are, however, several key
limitations. Most URL schemes (e.g., http) are defined for
resolution
service only. Any URL administration has to be done either at the
local
host, or via some other network service such as NFS. Using a URL
as a
name typically ties the Internet resource to its current network
location, and to its local file path when the file path is part of
the
URL. When the resource moves from one location to another, for
whatever
reason, the URL breaks.
strikes me as text that has been kicking around since Handles were
first
suggested, 6 or more years ago. This is an oversimplification of
URL(I)s,
and fails to acknowledge the use that several recent URI schemes
(URN, SIP, etc) route around this problem differently.
3. Handle System Architecture
The Handle System defines a hierarchical service model. The top
level
consists of a single global service, known as the Global Handle
Registry. The lower level consists of all other handle services,
which
are generically known as local handle services. The Global Handle
Registry provides a handle service (for resolution) and can be
used
to
manage any handle namespace.
Read carefully: the Global Handle Registry has a single root.
Although
it is replicable, it effectively recreates all the issues with DNS'
single-root, without demonstrably offering improvements. Note also
that
CNRI, the last I heard, is still the organization in charge of that
root.
It is possible that there might be multiple independent hierarchies
--
e.g., DOIs (Digital Object Identifiers) might have an independent
Handle
implementation/service deployment, with the International DOI
Foundation
in charge of the root. These could be distinguished by registering
different URI schemes (or URN namespaces) that each happened to use
the Handle technology.
But, it still means standing up one or more global services that
would
have the span of DNS (presuming the scope that this is targeted at
is
reached), using a protocol that has not had the engineering or
experience advantage of IETF input: the architecture is reasonable
for
distributing a large enterprise application-level service, but real
Internet systems also have to look at the impact of/on transport,
points of failure, security, DOS, rate of data update &
replication,
etc.
In particular,
The Global Handle Registry manages naming authority handles. Each
naming
authority handle maintains the service information that describes
the
"home" service of the naming authority. The service information
lists
the service sites of the handle service, as well as the interface
to
each handle server within each site. To find the "home" service
for
any
handle, a client can query the Global Handle Registry for the
service
information that is maintained by the corresponding naming
authority
handle. The service information provides the necessary information
for
clients to communicate with the "home" service for any request.
this is the functional equivalent of requiring every handle service
to push its SRV record(s) to a centrally-managed if
distributed-operation
server(ice). The data in the Global Handle Registry is more than
just the equivalent of NS pointers. Traditionally, keeping that
kind of data up to date beyond your own administrative control has
proven an operational challenge. So, I can think of reasons why
this
will be less successful than DNS's approach; I can't see (and they
didn't write) any solid reasons why it is manageable and better.
4. Handle System Service and its Security
There isn't enough detail in this document to know whether the
hand-wavey claims made are in fact justified by the architecture.
One would presume it would be clearer from the other 2 documents.
Nevertheless, substantiating the claims, at least to some degree,
would improve this document.
5. The Handle System and other Internet Services
[snip]
5.1 Domain Name Service (DNS)
The Domain Name Service, or DNS, was originally designed and is
heavily
used for mapping domain names into IP Addresses for network
routing
purposes. RFC1034 [2] and RFC1035 [3] provide detailed
descriptions
of
its design and implementation. The growth of the Internet has
increased
demands for various extensions to DNS, and even its possible use
as a
general purpose resource naming system. However, any such use has
the
potential to slow down the network address translation, and alter
its
effectiveness in network routing. DNS implementation typically
does
not
scale well when large amount of data is associated with any
particular
DNS name, and is generally considered not adequate to support a
very
large number of DNS names used for naming any kind of resources
over
the
Internet.
The authors have elected not to substantiate any of the claims
above.
I'm not a DNS operations expert, and while I respect there are
reasons not to do DNS-dumping, the lack of clarity and
substantiation
(and, possibly, correctness) in this exposition does no favours for
this paper.
An additional factor that argues against using DNS as a general
purpose
naming system is the DNS administrative model. DNS names are
typically
managed by the network administrator(s) at the DNS zone level,
with
no
provision for a per name administrative structure, and no
facilities
for
anyone other than network administrators to create or manage
names.
This
is appropriate for domain name administration but less so for
general
purpose resource name administration.
While this is a valid reason not to name all document objects with
DNS
names, that's not a proposal that has been seriously entertained
(at
least within the IETF) for years. What URNs do, for instance, is
leverage the DNS infrastucture to find local resolvers, which do
the
legwork of managing entries for individual objects. I.e., in the
current proposal, URNs use the DNS for the equivalent of the Global
Handle Registry (although there is a layer of indirection that
permits
migrating away from DNS for that purpose, if we can build a better
mousetrap).
And, the real collision with the DNS administration model is the
fact that, organizationally, domains evolve for different purposes
than docuemnt collections do (DNS is about your network objects,
not
your publishing departments), and their administration should
similarly be independent.
5.3 Uniform Resource Names (URN)
The IETF URN Working Group [12] has defined a syntax, possible
resolution mechanisms, and namespace registration procedure for a
resource identifier intended to cover a large array of existing
and
potential namespaces. Namespaces are to be registered and assigned
unique Namespace Ids (NIDs). Any resolution services associated
with
these namespaces require further registration with a Resolution
Discovery System (RDS) which clients could use to begin, or
discover,
the appropriate resolution mechanisms.
The objectives and some of the approaches of the URN and Handle
System
efforts have enough in common that some observers might think that
they
are in contention. This is not the case. The URN effort is
explicitly
designed to accommodate multiple identifier namespaces and
resolution
systems. The Handle System is one such case, with a very specific
data
and service model, and a protocol that supports name resolution
and
administration. URNs and the Handle System may interact in variety
of
ways, the most obvious of which is that handles could be
registered
as a
URN namespace, which is to say, they could be used as a type of
URN.
It
would also be possible to use the Handle System as a type of RDS
for
other URN namespaces. The success of either system however, is not
dependent upon the success of the other.
This is true. But it doesn't scratch the itch of: could you not
implement the same kind of thing as Handle seeks to, using more of
the material developed for URNs? Why recreate? For instance, I
don't
see why you couldn't achieve many of the "independent of DNS
name administration" by using the OID namespace defined in RFC
3061,
and then using the Handle protocol for the final resolution. The
advantage of that approach is that the administration of the name
service data would be closer to the name service itself, not some
centrally-managed global handle registry. There may be solid
technical
arguments why the Handle Global Registry approach is better -- but
it would be nice to see them _presented_, as if the authors had
even considered the possibility and set it aside on technical
merit.