[IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt

[Mark Baugher]

Sam,

At 03:02 AM 5/26/2001 -0400, Sam X. Sun \(@S2000\) wrote:
>Mark,
>
>By default, all handles under a naming authority are managed by a single
>handle service (or at least we encourage it being that way so that people

Maybe I'm confused here, but I'm thinking of two organizations, they might
be publishing companies who are competitors, that serve as naming authorities
for their respective publications.  One of the competitors transfers ownership
rights to the other and now one naming authority is referenced in the name
of the work while a second naming authority has all rights to the work.  So
I'm not considering the case of two services under one naming authority but
two different naming authorities.

Mark

>can use the cached service information). But this is not a requirement.
>Handles under a naming authority can actually be managed by different handle
>services. When this happens, a flag in the service information (see Service
>Definition draft) must be set to reflect this. The service information must
>also set its TTL to zero so that all caching services know not to use it
>when resolving different handles (under the same naming authority) at a
>later time. As you can see, the downside of this approach is that it
>undermines the caching functionality for handles under the naming authority
>(up to the service information), and that's why we don't recommend it.
>
>Another way to do it is via aliasing (or redirection), which does have the
>potential that client will be chasing around if the ownership changes many
>times, which you have pointed out.
>
>
>Sam
>
>
>----- Original Message -----
>From: "Mark Baugher" <mbaugher@cisco.com>
>To: "Larry Lannom" <llannom@cnri.reston.va.us>
>Cc: <ietf-idrm@lists.elistx.com>; <ssun@cnri.reston.va.us>
>Sent: Friday, May 25, 2001 2:17 PM
>Subject: Re: [IDRM] draft-irtf-idrm-handle-system-00.txt
>
>
> > Thanks for the clarification, Larry.  I have another question.
> >
> > At 09:28 AM 5/25/2001 -0400, Larry Lannom wrote:
> > >I'll let Sam answer the hard questions, but I believe your second point
> > >goes fairly directly to the 'semantically meaningful naming authority
> > >issue.' If the naming authority moving from X to Y is 10.3692 then the
> > >revealed information is a little obscure. If you have a good memory or
> > >access to administrative logs you may be able to tell that the
> > >handle10.3692/abc used to be owned and administered by X but has now
>moved
> > >to Y. If the handle was JohnWileyAndSons.JournalDivision/abc then the
> > >situation is a little more confusing. This has been the subject of a good
> > >deal of discussion over the years and I strongly encourage non-semantic
> > >naming authorities. The commercial publishing world, as an example,
> > >instinctively understands and supports this approach (cf.
> > >ISBNs) and in the DOI world we have already had at least one instance of
>a
> > >block of handles moving from one owner to another with no apparent
> > >problems (American Chemical Society selling a journal to Wiley). So there
> > >are two potential problems with the transfer of ownership of Handles or
> > >Handle NAs: 1) semantically meaningful NAs and 2) splitting a set of
> > >handles under one NA across two or more owners who want to administer
> > >their handles on different local handle services - this is possible
> > >because the granularity of ownership is at the individual handle level
>and
> > >a potential problem because clients are directed to local services by the
> > >global root based on NA. This situation hasn't arisen (all DOIs, e.g.,
>are
> > >in a single local service) but could be forbidden by local service policy
> > >(the DOI choice) or by providing clients with non-deterministic answers.
> > >This potential problem was a direct trade-off for 1) allowing local
> > >services and 2) putting ownership granularity at the handle level. So far
> > >it seems like the right choice.
> >
> > A big question for me is what happens when John Wiley, let's say they are
> > naming authority "167," transfers ownership of a work to Springer-Verlag
> > who are "203."  Since the work is prefixed with 167 forever, doesn't that
> > mean that John Wiley's naming authority will always get queried for this
> > work?  That the trust and security for this work will reside with a John
> > Wiley server and not with a Springer server?  Or will the John Wiley
>server
> > always need to redirect the client to the Springer server?  If so,
> > hopefully Springer won't sell it or it won't be sold many times - or else
> > the client will be chasing around the Internet for awhile.
> >
> > thanks, Mark
> >
> >
> >
> > >Larry
> > >
> > >At 09:36 PM 5/24/01 -0700, Mark Baugher wrote:
> > > >Here are the remaining questions and comments from the
> > > draft-irtf-idrm-handle-system-00.txt.  Regarding my previous comments,is
> > > it accurate to say that the Handle System protocols could in principle
>be
> > > used with a variety of different servers/resolvers including DDDS?
> > > >
> > > >I have five points.
> > > >
> > > >1)  Section 1, under "Secured Named Service" describes specific
> > > cryptographic mechanisms but "Distributed Administration Service" does
> > > not.  By briefly mentioning specific security and cryptographic
> > > mechanisms in this document, rather than in the later documents where
> > > they are specified, I think you raise more questions than you can answer
> > > in an Overview document.
> > > >
> > > >2)  Section 2, para 2, suggests that a persistent name can never be
> > > moved between naming authorities.  If all rights to a content work were
> > > completely transferred from a corporation operating naming authority x,
> > > to one operating naming authority y, then the content work will still
> > > have x in its name.  This seems like a problem to me.  The DOI Handbook
> > > makes a point about handles being "dumb numbers," but these handles
> > > reveal information that will persist even when no longer valid.
> > > >
> > > >3) Section 4, para 3, last sentence, defines an enormous PKI for a
> > > global namespace and I have some doubts about providing a security
> > > service for referencing potentially any content item in the world.  It
>is
> > > a scalability issue if the handle system is not designed for
> > > smaller-scale and private use or if the trust and security mechanisms
> > > cannot be tailored to the needs of individual organizations and national
> > > considerations.  There are large political issues here.  This is the
>main
> > > problem I have with the Handle System.  We may have an opportunity to
> > > consider this at length when discussing the next two drafts.
> > > >
> > > >4) Section 4, para 5, should discuss the assets to be protected (e.g.
> > > handle metadata), the risks to those assets (e.g. corruption of handle
> > > metadata), and the sources of threats (e.g. hackers seeking fame or
> > > criminals seeking fortune).  I believe the sentence "To trust a Local
> > > Handle Service means to trust that it will correctly respond with data
> > > that was entered by the administrator" is a too general to be useful.
> > > >
> > > >5) The document needs a security section and should follow the other
> > > guidelines for formatting and mandatory sections of RFC 2223.
> > > >
> > > >At 11:05 PM 5/22/2001 -0700, Mark Baugher wrote:
> > > >>Oh, by the way, this note is commenting upon
> > > draft-irtf-idrm-handle-system-00.txt and not
> > > draft-irtf-idrm-handle-system-protocol-00.txt - I made a mistake in the
> > > Subject line that I'll correct in subsequent responses.
> > > >>
> > > >>Mark
> > > >>At 10:26 PM 5/22/2001 -0700, Mark Baugher wrote:
> > > >>>I have a number of comments on this draft.  I also plan to post
> > > comments on the two other handle drafts,
> > > draft-irtf-idrm-handle-system-def-00.txt and
> > > draft-irtf-idrm-handle-system-protocol-00.txt.  I'll start with
> > > draft-irtf-idrm-handle-system-00.txt comments, a couple at a time since
> > > my other questions and comments may be resolved along the way.
> > > >>>
> > > >>>My first comment is that there does not seem to be name-resolution
> > > draft in the mix.  Is this not to be published?  I can see a lot of uses
> > > for a namespace that is not global, such as between a content provider
> > > (publisher) and service provider (distributor) that want to use the
> > > metadata facilities of handles to store rights information with the
> > > content work and to identify one or more "official repositories" for the
> > > content work.  If you're requiring a global namespace but not publishing
> > > the resolution mechanisms, then this seems to be an impediment to many
> > > business-to-business uses.
> > > >>>
> > > >>>Mark
> >