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

[Sam X. Sun (@S2000)]

Mark,

I was confused  your scenario with the multiple primary (service)
configuration. So ignore my earlier message on this, and let me know what do
you think of the following...

Basically, I think there are two ways to address the ownership change over
time. One is via the "handle alias", as described in the second draft "HS
namespace and service definition" (see
http://www.idrm.org/draft-irtf-idrm-handle-system-def-01.txt). In section
3.2.4, it says "When a resource identified by a handle transfers from one
organization to another, a new handle for the resource may be created. To
avoid inconsistency and broken references, the handle used before the
ownership transfer may be changed to a handle alias and its HS_ALIAS value
pointed to the newly created handle". Each handle alias can have its
administrator defined in terms of the new ownership so that they can be
managed by its owner, not the handle service where the handle alias is
residing on. Multiple aliases may be created if the ownership changes hands
many times. Each handle alias should be referring to the handle that points
to the final resource, to avoid clients chasing the aliases around. Thus in
the case you described earlier, when John Wiley (suppose whose naming
authority is 167) transfers ownership of a work referenced by handle 167/1
to Sprinter-Verlag (suppose whose naming authority is 203), Sprinter-Verlag
can create a new handle as 203/678 for that work, while John Wiley has to
convert 167/1 into a handle alias (for 203/678), and add John Wiley as the
administrator for 167/1 as part of the ownership transfer. Clients accessing
the work through 167/1 may make note of the ownership transfer via the
handle alias.

Another way to deal with ownership change is to "relocate" both naming
authorities (i.e. 167 and 203) onto the same handle service. Under this
scenario, all we need to do (for ownership transfer) is to add
Sprinter-Verlag as the administrator as the administrator for the John Wiley
handle (e.g. 167/1).

Does these may sense?

Thanks,
Sam



----- Original Message -----
From: "Mark Baugher" <mbaugher@cisco.com>
> 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.
>
> >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
> > >
>