[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Informational RFC to be: draft-irtf-idrm-handle-system-03.txt (fwd)
is there a RFC on URN that can be pointed to so that a reader will be
able to figure out what the IESG is trying to say ?
Scott
---
>From paf@cisco.com Thu Jan 23 07:47:14 2003
Date: Thu, 23 Jan 2003 13:46:47 +0100
Subject: Re: Informational RFC to be: draft-irtf-idrm-handle-system-03.txt (fwd)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mime-Version: 1.0 (Apple Message framework v551)
Cc: Scott Bradner <sob@harvard.edu>, iesg@ietf.org
To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@cisco.com>
In-Reply-To: <D6D3954E-23F3-11D7-871D-0003934B2128@cisco.com>
X-Mailer: Apple Mail (2.551)
X-OriginalArrivalTime: 23 Jan 2003 12:46:52.0246 (UTC) FILETIME=[80B14F60:01C2C2DD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by newdev.harvard.edu id h0NClEcm026838
I declare silence from Leslie/Rob and IESG being the same as "agree",
so I suggest the following IESG note:
Note To RFC-Editor:
IESG would like to add the following IESG Note:
IESG Note:
IETF have discussed the Handle system in the realm of URI related
working groups. IESG want to point out that there is not IETF consensus
on the current design of the Handle system, and where it fits in the
IETF architecture. IESG is of the view that that the Handle system
should be able to, with very small changes, fit in the IETF
architecture as a URN namespace.
paf
On torsdag, jan 9, 2003, at 18:00 Europe/Stockholm, Patrik Fältström
wrote:
> Good point.
>
> Leslie, as you happen to be on the IESG list _and_ is the designated
> expert "I have appointed ;-) what do you think?
>
> paf
>
> On torsdag, jan 9, 2003, at 13:14 Europe/Stockholm, Scott Bradner
> wrote:
>
>> 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.
>>>>
>>>
>>
>