Re: Fwd: Informational RFC to be: draft-irtf-idrm-handle-system-03.txt (fwd)

[Scott Bradner <sob@harvard.edu>]

should there be an IESG note pointing to the URN work?

----
>From iesg-admin@ietf.org  Thu Jan  9 03:45:23 2003
Date: Thu, 9 Jan 2003 09:43:21 +0100
Mime-Version: 1.0 (Apple Message framework v551)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Subject: Fwd: Informational RFC to be: draft-irtf-idrm-handle-system-03.txt (fwd)
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
To: IESG <iesg@ietf.org>
X-Mailer: Apple Mail (2.551)
X-OriginalArrivalTime: 09 Jan 2003 08:43:23.0945 (UTC) FILETIME=[2BAEF990:01C2B7BB]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id h098qMJ05926
Sender: iesg-admin@ietf.org
Errors-To: iesg-admin@ietf.org
X-BeenThere: iesg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/iesg>,
	<mailto:iesg-request@ietf.org?subject=unsubscribe>
List-Id: <iesg.ietf.org>
List-Post: <mailto:iesg@ietf.org>
List-Help: <mailto:iesg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/iesg>,
	<mailto:iesg-request@ietf.org?subject=subscribe>

I am resending this, as this item ended up on this weeks agenda without 
any discussion in IESG, of course because of x-mas.

Conclusion: I did evaluate this draft in November 2001, and Leslie 
helped with it.

It describes the Handle system correctly, and if IRTF want to publish 
it, I will not block. BUT, the Handle system is as you can see in 
Leslies summary not following the path IETF has chosen (the correct 
path would be to have Handle system as a URN scheme).

The Handle people have been told since around 1995, but they are still 
pushing.

Now obviously through IRTF. IETF has said no, if not a URN scheme is 
defined (and the only difference is whether hdl is a URI scheme or not, 
more or less).

     paf

Begin forwarded message:

> From: Patrik Fältström <paf@cisco.com>
> Date: ons dec 25, 2002  08:25:23 Europe/Stockholm
> To: IESG <iesg@ietf.org>
> Subject: Fwd: Informational RFC to be: 
> draft-irtf-idrm-handle-system-03.txt (fwd)
>
> Here is the review Leslie Daigle did for me way back, which IESG and 
> IAB was cc:ed on.
>
> Conclusion: IF the IRTF really want to publish this, that is fine with 
> me.
>
> But, this work disconnected from the IETF many moons ago, and have 
> nothing to do (as presented, and that is clear in the document) with 
> the URI/URN architecture as defined by work in the IETF.
>
>    paf
>
>
> Begin forwarded message:
>
>> 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.
>>
>